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SUBJECT: 


Internal Grganization of Muitics System Initialization 


SPECIAL INSTRUCTIONS: 


DATE: 


This document supersedes the previous edition of the manual, 
erder number AN70-00, dated February 1975. 


This System Designers’ Notebook describes certain internal 
modules constituting the Multics System. It is intended as 
a reference for only these who are thoroughly familiar with 
the implementation details of the Multics operating system: 
interfaces described herein should not be used by applica- 
tion programmers or subsystem writers; such programmers and 


writers are concerned with the external interfaces only. 
The external interfaces are described in the Multics 
Programmers" Manual, Commands and Active Functions (Order 
No. AG92) and Subroutines (Order No. AGS3). 


As Multics evolves, Honeywell will add, delete, and modify 
module descriptions in subsequent SDN updates. Honeywell 1 
dees not ensure that the. internal functions and internal 
medule interfaces will remain compatible with previous 
versions. 
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Multics System Designers' Notebeoks (SDNs} are intended for 
use by Multics system maintenance personnel, development person- 
nel, and others who are thoroughly familiar with Muitics internal 
system operation. . They.. are not intended for application 
programmers or subsystem writers. 


The SDBNs contain descriptions of modules that serve as 
internal interfaces and perform special system functions. These 
documents do not describe external interfaces, which are used by 
application and system programmers. 


This SDN contains a description of the software that 
initializes the Multics system. This description is by no means 
complete in all its details; for a thorough understanding of 
Multics initialization, or of any particular area within this 
system, this SDN should be used for reference in conjunction with 
the source of the relevant programs. 


(C) Honeywell Information Systems Inc., 1984 File No.: 2L13 
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In addition to this manual, the volumes of the Multics 


Programmers' Manual (MPM) should be referred to for details of 
software concepts and organization, external interfaces, and for 


specific usage of Multics Commands and subroutines. These 
volumes are: 
MPM Reference Guide, Order No. AG91 
MPM Commands and Active Functions, Order No. AG92 
MPM Subroutines, Grder No. AGS93 
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SECTION 1 


SUMMARY OF INITIALIZATIGN 


Multics initialization, as described in this SDN, can be 
thought of as divided into the following parts: 


* Hardware and PL/1 Environment initialization €Collec- 
tion 0) 

* Page Control initialization (Collection 1 service pass) 

* Bootload Command Environment (bce) (Collection 1 multi- 
ple passes) 

* Crash Handler (toehold) 

* File System initialization (Collection 2) 

* Guter ring Environment initialization (Collection 3) 


The parts listed before collection 2 are collectively called 
"Bootload Multics." 


A collection is simply a set of initialization routines 
that are read in and placed into operation as a unit to perform a 
certain set, or a certain subset, ef the tasks required to 
initialize a portion of the Multics supervisor. Each collection 
consists of a distinct set of programs for reasons discussed 
throughout this SDN. Even.though each... collection mostly exists 
to perform a particular set of functions, they are normally 
referred to by their number (which have only historical signifi- 
cance) rather than the name of their function. 


Initialization may also be thought of as having three 
seperate functions: 


Bringing up the system 
This role is obvious. The description of this role 
follows along the functions needed to perform it. Each 
portion of initialization runs, utilizing the efforts 
of the previous portions to buitd up more and more 
mechanism until service Multics itself can run. 


Providing a command environment before the file system is 


activated from which to perform configuration and disk 
maintenance functions 
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Providing an environment to which service Multics may crash 
which is capable of taking a dump of Multics and 
initiating recovery and reboot operations 


These last two functions are the role of bootload Multics 
(bce), They take advantage of the fact that during 
initialization an environment is built that has certain 
facilities that allow operations such as disk manipulation to 
eccur but it is an environment in which the disks themselves are 
not yet active for storage system operations. This environment, 
at an intermediate point in initialization, forms the bootload 
command environment (bce). 


The bootloead command environment is saved before further 


initialization operations occur. When service Multics crashes, 
service Multics is saved and this bce “crash" environment is 
restored, This safe environment can then examine or dump the 


service Multics image and perform certain recovery and restart 
operations without relying on the state of service Multics. 


HARDWARE AND PL/1 ENVIRONMENT INITIALIZATION 
The purpose of collection O is to set up the pl/l 
environment and to start collection 1. It has a variety of 


interesting things to perform in the process. First of all, 
collection O must get itself running. When Multics is booted 
from BOS, this is an easy matter, since BOS will read in the 
beginning of collection 0, leaving the hardware in a known and 
good state and providing a description of the configuration 
(config _deck) around. When not booted from BOS, that is, when 
booted via the [196M boot function, collection 0 has the task of 
getting the hardware into a good and Known state and finding out 
on what hardware it is working. Since collection O has set up the 
hardware, it can lead coliection 1 into memory. Collection 1 
contains the modules needed to support programs written in pl/t; 
thus, this loading activates the pl/1 environment. After this 
time, more sensible programs can run and begin the true process 
of initialization. The result of this collection is to provide 
an environment in which pl/l programs can run, within the 
confines of memory. 


PAGE. CONTROL, INITIALIZATION 


The main task of collection 1 is to make page control 
operative. This is necessary so that we may page the rest of the 
initialization programs Cinitialization programs all have to fit 
into memory until this is done). The initialization of page 
control involves setting up all of the disk and page control data 
bases. Also, the interrupt mechanism must be initialized. The 
result of this collection is to provide an environment in which 
i/o devices may be operated upon through normal mechanisms (Ci.e., 
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via page faults or direct calls to the standard device control 
medules) but in which the storage system is not active. At the 
final end of collection 1, this environment becomes paged, using 
a special region of the disks (the hardcore partition) so that 
the storage system is not affected. 


Collection 1 can be run multiple times. The effect of 
making a pass through collection 1 is to set up the device tables 
(and general configuration describing tables) to reflect a new 
configuration. The various passes of collection 1 are the key to 
the operation of bce. There are several times when the running 


of coliection i is necessary. It is necessary when we first 
Start up, to ellow accessing the hardware units “discovered” by 
collection O. Gince the correct configuration is determined via 


bce activities, collection 1 must be re-run to allow all of the 
devices to be accessible during the rest of initialization and 
Multics service proper. Finally, when the crash environment is 
restored (see below), another pass must be made to provide 
accessibility to the devices given the state at the time of the 
crash. 


FILE SYSTEM INITIALIZATION 


With paging active, collection 2 can be read into a paged 
environment. Given this environment, the major portion of the 
rest of initialization o¢curs. Segment, directory and traffic 
control are initialized here, making the storage system accessi- 
ble in the process. The result of this collection is an 
environment that has active virtually all hardcore mechanisms 
needed by the rest of Multics. 


OUTER RING ENVIRONMENT INITIALIZATION 
Collection 3 is basically a collection of those facilities 
that are required to run in outer rings. In particular, it 


contains the programs needed to provide the initializer's ring 
ene environment, especially the code to perform a reload of the 
system (especially the executable libraries). After the execu- 
tion of this collection, the Initializer enters into a-ring one 
command environment, ready to load the system (if necessary) and 
start up the answering service. (Activities performed from ring 
ene onward are not covered in this SDN.) 


BOOTLOAD COMMAND ENVIRONMENT (BCE) 


The bootload command environment is an environment that can 
perform configuration and disk management functions. It needs to 
be able to support i/o to devices in a pl/1 environment. Also, 
since bce must be able to operate on arbitrary disks, it must be 
capable of running before the storage system is active. Thus, it 
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is equivalent to the collection 1 environment before the environ- 
ment becomes paged. In this environment, built by a special run 
of collection 1, a series of facilities provides a command 
environment that allows pl/1 programs to run in a manner similar 
to their operation in the normal Multics programming environment. 


CRASH HANDLER (TOEHGLD) 


When Multics has crashed, Multics is incapable of 
performing the types of analysis and recovery operations desired 
im its distressed state. Thus, a safe environment is invoked to 
provide these facilities. Since bce is capabie of accessing 
memory and disks independently of the storage system (and the 
hardcore partitions), it becomes the obvious choice for a crash 
environment. When Multics crashes, bce is restored to operation. 
Facilities within &ce can perform a dump of Multics as well as 
start recovery and reboot operations. The crash environment 
consists of the mechanisms needed to save the state of Multics 
upon a crash and to re-setup the bootload command environment. 
These mechanisms must work in the face of varying types of system 
failures; they must also work given the possibility of hardware 
reconfiguration since the time the safe environment was saved, 
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SECTION 2 


COLLECTION O 


Collection O in Bootload Multics is . an ensemble of ALM 
programs capable of being booted from BOS or the IOM, reading 
themselves off of the boot tape, loading tape firmware if needed, 
setting up an 1/6 and error handling environment, and loading 
collection 1. 


Collection 19) is organized into two modules: 
bootload_tape_label, and bound_bootioad_O. The first is an MST 
label program designed to read the second into its correct memory 
location, after being read in by the IGM bootload program. The 
second is a bound collection of ALM programs. bound_bootload_0 
takes extensive advantage of the binder's ability to simulate the 
linker within a bound unit. The programs in bound_bootload_O use 
standard external references to make intermodule references, and 
the binder, rather than any run-time linker or pre-linker, 
resolves them to TSR-relative addresses, Any external references 
(such as to the config deck) are made with explicit use of the 
fact that segment numbers for collection O programs ere fixed at 
assembly time. 


GETTING STARTED 

boot load_tape_ label is read in by one of two means. In 
native mode, the IGM or I1I6C reads it into absolute location 30, 
leaving the PCW, DCW's, and other essentials in locations 0 


through 5. The I116C leaves an indication of its identity just 
after this block of information. 


In BOS compatibility mode, the BOS BOGT command simulates 
the IGM, leaving the same information. However, it also leaves a 
config deck and flagbox (although bce has its own flagbox} in the 
usual locations. This allows Bootload Multics to return to BOS 
if there is a BOS to return to. The presence of BOS is indicated 
by the tape drive number being non-zero in the idcw in the "IGM" 
provided information. 
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The label overlays the interrupt vectors for the first two 
ISM's. Because the label is formatted as a Multics standard tape 
record, it has a trailer that cannot be changed. This trailer 
overlays the interrupt vectors for channels BS and B10, Without 
a change in the label format, the bootload tape controller cannot 
use either of these channels as a base channel, because the label 
record wipes out the vectors that the ISM bootload programs sets 
up. This prevents control from transferring to the label 
program, 


The label program first initializes the processor by 
loading the Mode Register and the Cache Mode Register, and 
clearing and enabling the FPTWAM and the SDBWAM. it then reads aii 
of bound _bootload_0O off the tape. This action places the toehold 
and bootload_early_dump into their correct places in memory, in 
as much as these two modules are bound to be the first two 
objects in bound_bootload_oO. If this is successful, it transfers 
to the beginning of bootload_abs_mode through an entry in the 
toehold. (This entry contains the address of bootload_abs_mode, 
via the linking performed by the binder.) This program copies 
the template descriptor segment assembled into template_sit_ to 
the appropriate location, copies int_unpaged_page_tables and 
unpaged_page_ tables to their correct locations, loads the DSBR 
and the pointer registers, enters appending mode, and transfers 
to bootload_O. 


PROGRAMMING IN COLLECTION Q 


Collection O programs are impure assembly language pro- 
grams. The standard calling sequence is with the tsx2 instruc- 


tion. A save stack of index register 2 values is maintained 
using id and di modifiers, as in traffic control. Programs that 
take arguments often have an argument list following the tsx2 
instruction. Skip returns are used to indicate errors. 


The segment bootload_info, a cds program, is the repository 
of information that is needed in later stages of initialization. 
This includes tape channel and device numbers and the like. The 
information is copied into the collection 1 segment sys_boot_info 
when collection 1 is read in, 


MODULE DESCRIPTIONS 


pootload abs mode. alm 


As mentioned above, bootload_abs_mode is the first program 
to run in kound_bootload_oO. The label program locates it by 
virtue of atra instruction at a known place in the toehold 
(whose address is fixed); the tra instruction having been fixed 
by the binder. It first clears the memory used by the Collection 
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Oo data segments, then copies the template descriptor segment, 
int_unpaged_page_tables and unpaged _page_tables from 
template_slt_. The DSBR' is loaded with the descriptor segment 
SDW, the pointer registers are filled in from the ITS pointers in 
template_sIlt_, and appending mode is entered. boot load_abs_mode 
then transfers control to bootload_OSbegin, the basic driver of 
collection zero initialization. 


bootload O.aim 


bootload_O's contract is to set up the 1/90, fault, and 
console services, and then load and transfer control to coilec- 
tion 1. As part of setting up the [7/5 environment, it must load 
tape firmware in the bootload tape MPC if BOS is not present. 
bootload_G makes a series of tsx2 calls to setup each of these 


facilities in turn. It calls bootload_io$preinit to interpret 
the bhootload program left in low memory by the IOM/IIGC/IGX, 
including checking for the presence of BSS; 


bootload_flagbox$preinit to set flagbox flags according to the 
presence of BOS; bootload_faults$init to fill in the fault 
vector; bootload_slt_managerSinit_slt to copy the data from 
template_slt_ to the SLT and name_table; bootload_ioSinit to set 
up the IJI/6 environment; bootload_consoleSinit to find a working 
console and initialize the console package; bootload_loaderSinit 
to initialize the MST loading package; bootload_tape_fwSboot to 
read the tape firmware and load it into the bootload tape 
controller; boot load_loaderSload_collection to load Cellectian 
1.0; bootload_loader$finish te copy the MST loader housekeeping 
pointers to their permanent homes; and bootload_lLlinkerSprelink to 
snap ali links in Collection 1.90. 


Finally, the contents of bootload_info are copied into 
sys_boot_info. Control is then transferred to bootload_1. 


2 ences. 


As described below under the heading of 
“bootload_tape_fw.alm", tape firmware must be present on the MST 
as ordinary segments. It must reside in the low 256K, because 


the MPC's do not implement extended addressing for firmware 
loading. The tape firmware segments are not needed after the MPC 
is loaded, so it is desired to recycle their storage. It is 
desired to load the MPC before collection 1 is leaded, so that 
backspace error recovery can be used when reading the tape. The 
net result is that they need to be a separate collection. To 
avoid destroying the old correspondence between collection num- 
bers and sys_infoSinitialization_state values, this set exists as 
a sub-collection. The tape firmware is collection 0.5, since it 
is loaded before collection 1. The segments in collection 0.5 
have a fixed naming convention. Each must include among its set 
of names a name of the form “fwid. Tnnn", where “Tnnn" is a four 
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character controller type currently used by the BOS FWLOAD 
facility. These short names are retained for two reasons. 
First, they are the controller types used by Field Engineering. 
Second, there is no erase and kill processing on input read in 
this environment, so that short strings are advantageous. Note 
that if the operator does make a typo and enters the wrong 
string, the question is asked again. 


boot load consele. aim 


bootiocad_console uses bootload_io to do console I/6. Its 
initialization entry, init, finds the conscle on the bootiocad 
IOM. This is done by first looking in the config deck, if BOS 
left us one, or, if not, by trying to perform a 51 (Write Alert) 
comment. to each channel in .turnd.. Gnly console channels respond 
to this command. When a console is found, a 5? (Read ID) command 
is used to determine the model. 


The working entrypoints are write, write_nl, write_alert, 
and read_ line. write_nl is provided as a convenience, All of 
these take appropriate buffer pointers and lengths. Read_line 
handles timeout and operator error statuses. 


There are three types of console that bootload_console must 
support. The first is the original EMC, CSU6001. It requires 
all its device commands to be specified in the PCW, and ignores 
IDCW's., The second is the Ltt, cCsu6601. It will accept commands 
in either the PCW or IDCW's. The third type is the IPC-CONS-2. 
In theory, it should be just like the LCC except that it does NOT 
accept PCW device commands. Whether or not it actually meets 
this specification has yet to be determined. 


To handle the two different forms of I1/& (PCW commands 
versus IDCW's), hbootload_console uses a table of indirect words 
pointing to the appropriate PCW and DCW lists for each operation. - 
The indirect words are setup at initialization time. The Lec is 
run with IDCW's to exercise the code that is expected to run on 
the IPC-CONS-2. 


bootload dseq. alm 

bootload_dseg's task is to prepare SDW's for segments 
loaded by bootload_ loader, the collection zero loader. 
bootload_ dseg$make_sdw takes as an argument an sdw_info structure 
as used by sdw_util_, and constructs and installs the SDW. The 


added entrypoint boot load_dsegtmake_core_ptw is used by 
bootload_loader to generate the page table words for the unpaged 
segments that it creates. 
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boot load early dump. alm 


When an error occurs during early initialization, 


bootload_early_dump is called. It is called in three ways. 
First, if bootload_error is called for an error (as opposed to a 
warning), this routine is called. Secendly, if a crash should 


eccur later in initialization Cafter collection 0) but before the 
toehold is set up (and bce running), the toehold will transfer 
here. Third, the operator can force a transfer to this routine 
through processor switches any time up until collect_free_core 
runs. (This includes while bce is running.) This is done by 
force executing a "tra 300000" instruction. 


bootload_early_dump starts by reestablishing the collection 
O environment (masked, pointer registers appropriately set, 
etc.). It then uses bootload_console to ask for the number of a 
tape drive on the bootlioad tape controller to use for the dump. 
When it gets a satisfactory answer, it dumps the first 512k of 
memory (that used by early initialization and bce), one record at 


a time, with a couple of miscellaneous values used by 
read_early_duinp_ tape (which constructs a normal format dump). lf 
an error occurs while writing a record, the write is simply 
retried (no backspace or other error recovery). After 16 


consecutive errors, the dump is aborted, a status message 
printed, and a new drive number requested. 


bootload error. alm 


bootload_error is responsible for all the error messages in 


collection O. It is similar in design to page_error.alm; there 
is one entrypoint per message, and macros are used to construct 
the calls to bootload_formline and bootload_console., 
bhootload error also contains the code to transfer to 
boot load_early_ dump. There are two basic macros used: "error", 
which. causes... a crash with message, and "warning", which prints 


the message and returns. All the warnings and errors find their 
parameters via external references rather than with call parame- 
ters. This allows tra's to bootload_error to be put in error 
return slots, like: 


tsx2 read_word 
tra boot load_errorSconsole_error 

“ error, status in 

" boot load consoles last_error_status 
es " normal return 


Warnings are called with tsx2 calls. 
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beotiocad faults.alm 


bootload_faults sets up the segment fault_vector. All 
faults except timer runout are set to transfer to 
boot load_error$unexpected_fault. All interrupts are set to 
transfer control to bootload_errorSunexpected_interrupt, since no 
interrupts are used in the collection zero environment. The same 
structure of transfers through indirect words that is used in the 
service fault environment is used to allow individual faults to 
be handied specially by changing a pointer rather than 
constructing a different tra instruction (also, instructions do 
not allow “its” pointers within them). The structure of the 
scu/tra pairs (but not the values of the pointers) formed by 
bootload_faults is that used by the rest of initialization and 
service. 


bootload flagbox, alm 


bootload_flagbex zeroes the bce flagbox. It also zeroes 
the cold_disk_mpc flag when BOS is present for historical 
reasons. Various values are placed in the flagbox that no one 
looks at. This program is responsible for the state of the BOS 
toehold as well. It copies the BOS entry sequences into the bce 
toehold and sets the bce entry sequence into the BGS toehold for 
the sake of operators who enter the wrong switches. 


bootload formline.alm 


This program is @ replacement for the BOS erpt facility. 
It provides string substitutions with ioa_-like format controls. 
It handies cctal and decimal numbers, BCD characters, ascii in 
units of words, and Acc strings. Its only client is 
boot load_error, who uses it to format error message. The BCD 
characters are. used to. print firmware ID's found in firmware 
images, Its calling sequence is elaborate, and a macro, 
"formline", is provided in bootload_formlins. incl.alm 


beotload info.cds 


The contents of this segment are described under data 
bases, 


booticad io.alm 

bootload_io is an io package designed to run on IGM's and 
11oC's. It has entrypoints to connect to channels with and 
without timeouts. It always waits for status after a connection. 


It runs completely using abs mode i/o, and its callers must fill 
in their DCW lists with absolute addresses. This is done because 
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NSA ISM'S do not support rel mode when set in PAGED mode, and 
there is no known way to find out whether an IGM is in paged 
mode. Under normal operation, the config card for the IGM is 
available to indicate whether the I6M is in paged mode or not, 
relieving this difficulty. 


The preinit entrypoint is called as one of the first 
eperations in collection O, Besides setting up for i/o, it 
copies and determines from the IGM/IIOC/BOS provided boot info 
the assume_config_deck (BOS present) flag and the system_type 
value, 


beotlcad lLinker.alm 


bootload_linker is responsible for snapping all links 


between collection one segments. It walks down the LOT looking 
for linkage sections to process. For each one, it considers each 
link and snaps it. It uses hbootload_slt_manager$get_seg ptr to 


find external segments and implements its own simple definitions 
search. 


beot load loader, ain 

bootload_loader is the collection zero loader (of collec- 
tions 9.5 and 7). It has entrypoints to initialize the tape 
loader (Cinit), load a@ collection (load_collection), skip a 
collection (skip_collection}, and clean up (finish). The loader 
is an alm implementation of segment_loader.pll, the collection 1 
loader. It reads records from the mst, analyzes them, splitting 


them into sit entries, definitions and linkage sections, and 
segment contents. Memory is obtained for the segment contents 
using allocation pointers in the slit. Page tables are allocated 
for the segment within the appropriate unpaged_page_tables seg- 
ment. When proper, the breakpoint.page .is added as another page 
to the end of the segment. Definitions and linkage sections are 
added to the end of the proper segments (ai_linkage, wi_ linkage, 
wS_ linkage, as_linkage). The loader has a table of special 
segments whose segment numbers (actually ITS pointers) are 
recorded as they are read in off of the tape. These include the 
hardcore linkage segments, needed to load linkage sections, 
definitions_, and others, The leader maintains its current 
allocation pointers for the linkage and definitions segments in 
its text. bootload_loadersfinish copies them into the headers of 
the segments where segment_loader expects to find them. 


bootload sit manager.aim 
bootload_slt_manager is responsible for managing the Seg- 
ment Loading Tabie (SLT) for callection zero, It has three 


entries. bootload_slt_managerS$init_silt copies the SLT and name 
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table templates from template_slt_ to the slt and name_table 


segments. boot load_slt_manager$bui ld_entry is called by 
bootload_loader to allocate a segment number and fill in the SLT 
and name table from the information on the MST. 


boot load_slt_managerSget_seg_ptr is called by bootload_linker to 
search the SLT for a given name. It has imbedded in it a copy of 
hash_index_ used to maintain a hashed list of segment names 
compatible with the list for slt_manager in further collections. 


booticad tape fyw.alm 


bootload tape_fw is responsible for loading the booticad 
tape MPC. It begins by toading collection 0.5 into memory with a 
call to boeotlcad_loader$ load_collection. By remembering the 
value of slt., last_init_seg before this. call, bootload_tape_fw can 
tell the range in segment numbers of the firmware segments. 
Firmware segments are assigned init_seg segment numbers by 
boot load_ loader, but are.loaded low in memory, for reasons 
described above. bootload_tape_fw then determines the correct 
firmware type. If bootload_info specifies the controller type, 
then it proceeds to search the SLTE names of the firmware 
segments for the appropriate firmware. If bootload_info does not 
specify the firmware type, then bootload_tape_fw must ask the 
operator to supply a controller type. This is because there is 
no way to get a controller to identify itself by model. 


Each of the firmware segments has as one of its SLTE names 
(specified in the MST header) the six character MPC type for 
which it is to be used. bootload_tape_fw walks the slt looking 
for a firmware segment with the correct name. If it cannot find 
it, it re-queries (or queries for the first time) the operator 
and tries again. 


Having found the right firmware, the standard MPC bootload 
sequence is initiated to boot the. tape. .MPC. The. firmware 
segments’ SDW's are zeroed, and the slt allocation pointers 
restored to their pre-collection-0.5 values. boot load tape_fw 
then returns. 


template sit .alm 
This alm program consists of a greup of invelved macros 
that generate the SLTE's for the segments of collection zero. It 


is NOT an image of the segment silt, because that would include 
many zero SLTE’s between the last sup seg in collection zere and 
the first init seg. Instead, the init seg SLTE's are packed in 
just above the sup segs, and bootload_slt_managerSinit_slt 
unpacks them. It also contains the template descriptor segment, 
packed in the same manner, and the template name table. The 
initial contents of int_unpaged_page_tables and 
unpaged _page_tables are also generated. Also present are the 
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absolute addresses, lengths, and pointers to each of the collec- 
tion 0 segments for use elsewhere in bound_bootload_O. 
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SECTION 3 


COLLECTION 1 


The basic charter of collection 1 is to set up paging, 
fault handling, as well as various data bases needed for paging 
and other like activities. Collection 1 can run multiple times, 
for various reasons. 


SUMMARY SF COLLECTION 1 PASSES 

The first run through collection 1 is Known as the “early” 
pass which is described below. It is arun in which we are 
restricted to work within 512K and in which only the rpv is 
known; in fact, it is this pass which finds the rpv and the 
config deck. If BOS is present, this pass is not needed. The 


end of this pass is the arrival at "early" command level, used to 
fix up the config deck, in preparation for the "boot" pass. 


The second pass, which is known as "“"bootload Multics 
initialization", @lso runs only within 512K. It, however, has 
knowledge of all disks and other peripherals through the config 
deck supplied either by BOS or the early initialization pass. 
This pass is made to generate a crash-to-able system that can be 
saved onto disk for crash and shutdown purposes. After the crash 


handler (this image) is saved, the bootioad Multics "boot" 
command level can be entered. This level allows the booting of 
Multics service. After Multics has shut down, a slight variant 


of this pass, the "shut" pass, is run in a manner similar to that 
for the "crash" pass, described below. 


The third pass (which actually comes after the fourth) is 
another run of bootload Multics initialization performed after 
Multics has crashed. This pass is made to re-genérate various 
tables to describe the possibly different configuration that now 
exists after having run Multics. Bootload Multics "crash" 
command level is then entered. 


The fourth pass through collection 1 is called "service 
initialization’, which runs using all memory and devices. The 
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result of this pass is suitable for running the later collec- 
tions, and bringing up service. 


The “sarily” pass creates a safe environment consisting of a 
set of programs in memory anda synthesized config deck that 
describes known hardware. This is saved away to handie crashes 
during the "boot" pass. If the “boot" pass fails, the toshold 
restores this earlier saved envirenment which then runs a 
"re early" pass. This is really @ normal pass, but using the 
saved away config deck of known good hardware. The "re_early” 
pass comes back to an "“sarly" command level to allow the operator 
to fix the deck or hardware. 


When the "hoot" pass succeeds, it also saves a good memory 
image and the now confirmed site config deck. After the “boot" 
pass saves this image, the “boot" command level is entered and 
eventually it boots Multics, running the "service" pass. If this 
fails, the toehold restores the saved image. A "“bce_crash" pass 
then runs. This is a normal pass but one in which the saved 
config deck is used. This pass is run on the assumption that, 
either a bce command died and the operator may now examine it, or 
that the "service" pass found a problem. The "bce_crash" level 
allows the operator to fix things. 


Gnce the boot of service Multics completes collection 1, a 
crash or shutdown will invoke the toehold to restore bce. This 
time, however, the current config deck is used to utilize any 
reconfigurations that have occured. bce will come to the "crash" 
or "boot" command levels, 


We'll start by looking at the basic initialization pass, 
that used to come to the normal ("beet") bce command level. 


NORMAL (BOGT) PASS 


The sequence of events in a normal initialization pass is 
given here. As of the time of the Start of a normal 
initialization pass, the config deck has been found, either by 
BOS or the early initialization pass. All other data bases 
besides sys_boot_info and sys_info set or created during previous 
initialization passes have been deleted. The pass starts with 
saving certain attributes, such as free core extents, for later 
restoration at the end of the pass (before running another). 


scs_and_clock_init fills in the initial secs (system config- 
uration segment) data from the config deck. This is information 
on the processors and the memory controllers. 


get_io_segs, iom_data_init, ocdem_Sinit_all_consoles, and 


scas_init are run to set up the disk_seg, pvt, iom_data, 
ioi_data, oc_data and the system controller addressing segment. 
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tc_init initializes tc_data's apte and itt lists. 


init_sst generates the sst and core map appropriate for the 
pass. This is the last real memory allocation. After this time, 
allocation of memory based upon the data in the silt is 
deactivated. The remaining tables either have memory already 
allocated for them or are generated paged, once paging is 
started, announce_chwm announces memory usage. 


initialize _faults$interrupt_init initializes the interrupt 
vector, With iom_data and oc_data set up, this permits ocdem_ to 
be used for console I/G., Tne interrupt mask is opened with a 
call to pmutSset_mask. 


The basic command environment facilities C!I/6 interfaces 
and a free area) are set up in a call to init bce. (BCE is an 


acronym for Bootload Command Environment). This allows programs 
that query the operator to do so in a more friendly fashion than 
raw calls to ocdem_. Further descriptions of bce facilities 


follow later. 


lead_disk_mpcs runs fonly during a "“boot" pass and only 
when we do not have BOS present} to make sure that all disk mpcs 
have firmware active within them. 


init_pvt, read_disk$init and init_rooet_vols together have 
the net effect of setting up disk and page control. No segments 
are paged at this time, though, except for rdisk_seg. Once we 
reach here, we Know that the config deck describes a set of 
hardware sufficient Cand valid) enough to reach command level and 
so we save the config deck as safe_config_deck. 


establish_temp_segs maps the bootload paged temp segments 
onto the reserved area for them in the "“bce" partition. 
find_file_partition maps the bce file system area 
(bootload_file_partition) unto the “file" partition. 


load_mst$init_commands maps the pagable bce programs onto 
the areas of disk in which they were read by load_mst earlier. 


If this is a "early" or “boot" pass, this environment is 
saved and the toehold setup to invoke it. This is done by 
init_toehold. The "early" pass saves the entire environment; the 
"boot" pass simply saves the safe_config.deck so determined by 
this pass. 


bce_get_to_command_level can now be called to provide the 
appropriate bce command level. At the "early" command level, the 
config deck must be made to be correct. At the “boot" command 
level, the mpcs (other than the bootload tape mpc and all of the 
disk mpcs) need to be loaded. 
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Within the command level, the config deck fon disk, 
disk_config deck} may have been modified. This is read in, via 
establish config _deck, for the next initialization pass. For 
cold boots, the generated config deck is written out instead, 


When the pass is over, the states saved at the beginning of 
the pass are restored, the system is masked, and we proceed to 
perform another pass. 


SERVICE PASS 


The sequence of events in a service pass differs from the 
normal pass in many ways. 


After initialize_faults$fault_init_one runs, 
move_non_perm_wired_segs is called to move the segments loaded by 
collection 0 to their proper places, thereby utilizing all of the 
bootload memory. 


[Collection O assumes 512K of bootload memory, for two 
reasons. First, if BOS and the config deck are not present, 
there is no easy way of finding out how much memory there is, so 
some assumption is needed. Second, the crash handler will have 
to run in some amount of memory whose contents are saved on disk. 
512K is areasonable amount of space to reserve for a disk 
partition. At current memory and disk prices it is hard to 
imagine anyone with a bootload controller with less that 512K, or 
a problem with the disk partition. 


When setting up the service environment, though, it is 
necessary to move the segments that have been allocated in the 
512K limit. It is desirable to have sst_seg and core_map at the 
high end of the bootload memory controller. (Gn the one hand, 
the controller they reside in cannot be deconfigured. Gn the 
other hand, only the low 256K of memory can be used for I/G 
buffers on systems with IOM's net in paged mode. While we could 
just start them at the 256K point, that might produce 
fragmentation problems. So the top of the controller is best.) 
If the controtler really has 512K of memory, collection 1 paged 
segments will be there. move_non_perm_wired_segs takes the 
segments that the collection zero loader allocated high (paged 
segments and init segments that are not firmware segments) and 
moves them to the highest contiguously addressable memory, 
hopefully leaving the top of the low controller fer the sst_seg 
and core_map. ] 


tc_init sets the number of aptes and itt entries om the 
basis of the tcd card, A normal bce pass really needs no such 
entries. 

init_sst generates the sst and core map appropriate for all 
of memory at the top of the bootload memory. A normal pass 
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allocates these tables through normal off-the-slt allocation 
(because the top of the 512k area is filled with temp segs). 


Since the service pass does not come to bce command level, 
establish_temp_segs, find _file_partition and 
load_mstSinit_commands are not run. 


init_toehold is not run since upon a crash we want to 
return to the bootload environment and not to a state in which we 
are booting. 


init_partitions checks the "part" config cards. 


Now, the routine we've all been waiting for runs. 
make_seqs_paged causes all pagable segments to be paged into the 
various hardcore partitions thereby mo longer needing memory. We 
can then run collect_free_core toe regain the freed space. 


delete_segs$temp deletes the segments temporary to collec- 
tion 1. We can then load, link, and run collection 2 (performed 
by segment_loader, pre _link_he and beyond), 


EARLY PASS 


The early initialization pass is a pass through collection 
1 whose job is to set up paging and obtain the config deck from 
its disk partition sc that anormal initialization pass may be 
run which Knews about the complete set of hardware. 


It starts with init_early_config constructing a config deck 
based on assumptions and information available in sys_boot_info. 
This config deck describes the bootload CPU, the low 512K of 
memory, the bootload IGM, the bootload tape controller and the 


bootioad console. Given this synthetic deck, we can proceed 
through scs_and_clock init, etc. to setup the environment. for 
paging. scs_and_clock_initSearly fills the bootload CPU port 


number into the config deck, which is how it differs from 
scs_and_clock_initSnormal. 


scas_init and init scu (called from scas_init) have special 
cases for early initialization that ignore any discrepancy 
between the 512K used for the bootload controller and any larger 
size indicated by the CPU port logic. 


During the early pass (or, actually during the first "boot" 
pass, if an early pass is never run), init_bceS$wired sets up 
references in bce_ data to wired objects. This allows 
bce_console_io and other friendlier routines to run, 


To lecate the RPY subsystem, find _rpv_subsystem looks in 


sys_boot_info. If the data is there, it will try to boot the RPV 
subsystem firmware (Cif needed). If not, it queries the operator 
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for the data. If, later in initialization, the data should prove 
suspect (¢4.g. RPY label does not describe the RPV), control 
returns here to re-query the operator. The operator is first 
asked for a command tine specifying the RPV subsystem model and 
base channel, and the RPV drive model and device number. The 
operator may request that the system.generate a query in detail 


for each item. Cold boot is also requested in the 
find _rpv_subsystem dialog. The simple command processor, 
bce_command_processor_, is used to parse the “cold” and "“rpv" 


request lines described above. 


The RPV data is fitted into the config deck, and 
initialization continues with init pvt and friends. 
init_root_vols is called through its early entrypoint so as to 
allow for an error return. Errors occuring during the initing of 
the rpv will cause a re-query of the rpv data by returning to the 
call to get_io_segs. 


Firmware is booted in the RFV controller by 
boot_rpv_subsystem, called from find_rpv_subsystem, which finds 
the appropriate firmware image and calls hc_load_mpc. A database 
of device models and firmware types and other configuration 
rules, config _data_.cds, is used to validate operator input and, 
for example, translate the subsystem model into a firmware 
segment name. 


init_roots_vols checks for the presence of and creates 
certain key partitions on the rpv. The "conf" partition, if not 
present, is created by trimming 4 pages off of the hardcore 
partition. The "bce" (bce crash handler, temporary area and MST 
storage) and “file" (boot load file system) partitions are 
created, if any is not found, by a call to create_rpv_partition. 
This program shuffles the disk pages to find enough contiguous 
space at the end of the disk for the partitions. 


After running establish _temp_segs and. find_file_partition, 
the rest of the MST is read. This step is performed during the 
"early" pass or whatever is the first boot pass. 
tape_readerSinit sets up tape reading. load_mst reads in collec- 
tion 1.2 (config deck sources and exec_coms) into bce file system 
objects, collection 1.5 (bce paged programs and firmware images) 
into mst area pages leaving around traces for 
load_mst$init commands (which maps them into the bce address 
space) and saves collections 2 and 3 on disk for warm booting. 
tape_reader$Sfinal shuts down the tape. load_mst$ init_ commands 
then runs. 


The early or the first boot pass then initializes bce_data 
references to paged objects with init _bceSpaged. 


An early command level is now entered, using a subset of 


the real bce command level commands. This level is entered to 
allow editing of the config deck. 
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After leaving command level, init clocks is called. This 
is the time when the operator sets the clock. Up until this 
time, the times shown were random. {f the operator realizes at 
this time that he must fix the config deck, or whatever, he has a 
chance to return to the early command level. When the clock is 
set, control proceeds. 


At this point, early initialization's work is dane. The 
real config deck is read in (by establish_config_deck), and the 
system can rebuild the wired databases to their real sizes. 
Interrupts are masked, completion of pending console I/6 is 
awaited, and the silt aliocation pointers are restored to their 
pre-collection-1 values. Control then meves to the “bost" pass. 


CRASH PASS 
The crash pass recreates a "boot" environment from which 
dumps can be taken and emergency _ shutdown can be invoked. It 


differs from the "boot" pass only in the verbosity (to avoid 
printing many messages at breakpoints} and in the command level 
that is reached. 


RE EARLY PASS 


A re_early pass is run to restore a safe environment 
following a failure to boot to the "boot" command level. It is 
identical to a "boot" pass except that it uses a saved config 
deck Known to be good and reaches a "early" command level. 


BCE CRASH PASS 


The bce_crash pass is run to restore a safe environment 
following a failure to boot the "service" pass. This-may also be 
the result of a failure of a bce utility invoked at the "boot" 
command level. This pass is identical to the boot pass except 
that it uses a saved config deck Known to be good and reaches the 
"bce_crash" command level. 


SHUT PASS 
The shut pass is run when Multics shuts down, as opposed to 
crashing. It differs from the boot pass only in that 


load_disk_mpcs is not run, because it shouldn't be ncessary 
(Multics was using the mpcs okay) and because it would interfere 
with possible auto exec_com operation. 
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MEDULE DESCRIPTIONS 


Bootload Command Environment modules are not included in 
this section, 


announce chwm.pl] 


The name of this program means 
announce_Core_High_Water_Mark. It will announce the extent to 
which memory is filled during the various passes of collection 1 
when the "“chwm" parameter appears on the “parm” card in the 
config deck, Near the beginning ef each pass, this program 
announces the amount of memory used, based upon information in 
the slt. At the end of service initialization, it walks down the 
core map entries, looking for pages that are available to page 
control and those that are wired. The difference between the 
memory size and the total figure given here is the amount taken 
up by non-page control pages, the sst for example. As a side 
bonus, the before entr ypoint announces the usage of 
int_unpaged_page_tables; the after entrypoint announces the usage 
for unpaged _page_tables. 


boot rpv subsystem.p11 
boot_rpv_subsystem is the interface between 


find rpv_subsystem and hc_load_mpc, the hardcore firmware loading 
utility. All that it really has to do is find the appropriate 


firmware segment in collection 1. config data_ is used to map 
the controller model to afirmware segment name, of the usual 
(T&D) form (fw. XXXnnn. ¥mmm). The segment and base channel are 


passed to hc_load_mpc, and the results (success or failure) are 
returned to find rpv_subsystem. 


This is the program that performs reading of the MST by 
collections 1 and beyond. It uses the physical record buffer as 
an i/o area, io_manager is used to perform the i/o, with dew 
lists generated within this program. 


boot load 1.aim 
bootload_1 is the first collection 1 pregram, called 
directly by collection 0. It fills in the stack headers of the 


prds and inzr_stkO to initialize the PL/1 environment. It then 
calls initializer.pli which pushes the first stack frame. 
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collect free core pill 


At the end of collection 1 service initialization, this 
program is called to free the storage taken up by the previously 
wired initialization segments. It does this by marking all core 
map entries for pages still unpaged (judged from the address 
field of the sdws of all segments) as wired and marking ail of 
the rest as free (tavailable for paging). It special cases 
breakpointable segments to avoid freeing references to 
breakpoint_page. 


create rey partition.pil 


To save the effort of creating the new Bootload Multics 
partitions by requiring all. sites to perform a rebuild_disk of 
their rpv, this program was created. It creates partitions on 
rpv Chigh end) by shuffling pages about so as to vacate the 
desired space. The pages to move are found from the vtoces. The 
vtoces are updated to show the new page location and the volmap 
is updated to show the new used pages. This program uses 
read_disk to read and write the pages. No part of the file 
system is active when this program runs. 


delete segs.pll 


delete_segs is called after the various collections to 
delete the segments specific only to that collection (temp segs). 
It is also called at the end of collection 3 to delete segments 
belonging to all of initialization Cinit segs), It scans the ast 
list for the appropriate segments, uses pesStruncate to free their 
pages (in the hardcore partition) or pc$cleanup to free the core 
frames for abs-segs and then threads the astes into the free 
list. This program is careful not to truncate a breakpoint_page 
threaded onto a segment. see 


disk reader pill 


disk_reader is used by the collection 1 loader (of collec- 


tion 2), segment_ loader, and by the collection 2 loader, 
load_system, to read the mst area of disk. It operates by paging 
disk through disk_mst_seg. The init entrypoint sets up 


disk_mst_seg unto the first 256 pages of the mst area to be read, 
AS requests come in to read various words, they are paged from 
this segment. When a request comes in that is longer than what 
is left in this segment, the remainder is placed into the 
caller's buffer, and disk_mst_seg re-mapped onto the next 2565 
pages. This continues as needed. 
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establish config deck pil 


The config deck is stored in the "conf" partition on the 
RPV in between bootloads. It runs in one of two ways, depending 
on whether it is setting up for service or bce use. For bce use, 
a abs-seg is created which describes the disk version. 
config_deck still describes the memory version. If it is 
necessary to read in the disk version, abs_seg is copied to 
config deck. Likewise, if some program (config_deck_edit_ in 
particular) wants to update the disk version, abs_seq is again 
used, receiving the contents of config_deck. During service, 
config deck is itseif both wired an an abs-seg on the disk 
partition. This is dene by creating an aste whose ptws describe 
memory. We make the core map entries for the pages occupied by 
config deck describe this aste and the disk records of the conf 
partition. These cme's are threaded into page . controls list 
(equivalent of freecore) providing a2 valid wired segment, at the 
address of config_deck. 


fill vol extents .pl) 


This is the ring 1 program that obtains, through the 
infamous "init vol laop”, the desired parameters of a disk to 
initialize. It is called in initialization by init _empty_root 
when performing & cold boot to determine the desired partitions 
and general layout desired for the rpyv. 


find rev subsystem. oll 

find_rpv_subsystem initializes configuration and firmware 
for the RPV disk subsystem. When evailable, it uses information 
in sys_boot_info. When that information is not present, the 


operator is queried. The basic query is for a request line of 
the form: 


rpv Ice MPC_model RPV_medel RPV_device 
or 
cold Icc MPC_model RPV_model RPV_device 


as described in the MGH. 


If the operator makes a mistake, or types help, the 
operator is offered the opportunity to enter into an extended, 
item by item dialog to supply the data. 


The information is checked for consistency against 
config_data_, a cds program that describes all supparted devices, 
models, etc, The mpc is tested through 
hc_load_mpc$test_controller, to see if firmware is running in it. 
If the response is power off, then boot_rpv_subsystem is called 
to load firmware. Then init_early_config$Sdisk is catied to fili 
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this data into the config deck. If a later stage of 
initialization discovers an error that might be the result of an 
incorrect specification at this stage, control is returned here 
to give the operator another chance. 


The operator is also allowed to enter "skip_load" or 
"skip", as a request before entering the rpv data. This forces a 
skip of the firmware loading, regardless of the apparent state of 
the mpc. 


set is segs pli 


A scan through the config deck determines the sizes of the 
Various hardcore i/o databases which this program allocates. 
This program also fills in some of the headers of these databases 
as a courtesy for later initialization programs. The key 
determiners of the sizes of the tables allocated are the number 
of subsystems, the number of logical channels to devices, the 
number of drives, the number cf ioms, etc. get_main is used to 
allocate the areas, using entries in the slt to find the memory. 
Areas allocated are: the pvt, the stock_segs, the disk_seg, 
ioi_data, iom_data and io_config_ data. 


get main. pil 


get_main is used to create a segment that is to reside in 
main memory. It runs in one of two ways, depending on whether 
allocation off the silt (slt.free_core_start) is allowed. When 
this is not allowed (later in initialization), 
make_sdwSunthreaded is used to generate the segment/aste. 
pc_absSwire_abs contig forces this segment to be in memory. 
Earlier in initialization (before page control is active), the 
segment is allocated from the free core values in the slt. These 
values determine the placement in memery of the to be created 
segment. get_main allocates a page table for this segment in 
either int_unpaged_page_tables or unpaged page_tables (depending 
on whether the segment will eventually be made paged). The ptws 
are filled in and an Sdw made. The given_address entrypoint of 
get_main can be used to utilize its unpaged segment page table 
generation capabilities (as in init sst). 


he_ load mec. pill 


hc_load_mpc embodies the protocel for loading all MPC's. 
It is an io_manager client. Since the firmware must be in the 
low 256K, a workspace is allocated in free_area_1 and the 
firmware image is copied out of the firmware segment and into 
this buffer for the actual 1/G, The urc entrypoint is used to 
load urc mpcs. This entry accepts an array of firmware images to 
load. It scans the list to determine to which channels cach 
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overlay applies. The extra entrypoint test _controller, used by 
find _rpv_subsystem and load disk_mpcs, tests a controller by 
executing aA request status operation. The results of this are 
used to see if the mpc seems to be running (has firmware in it). 


init aste peols.pllL 


This program is called exclusively from init sst and really 
does most of its work. It builds the four aste pools with empty 
astes appropriately threaded, Each aste is filled in with ptws 
indicating null pages. 


init clocks.pl 


This program performs the setting of the system clock. It 
starts by providing the time and asking if it is correct. If it 
is, fine. If the operator says it's not, the operator is 


prompted for a time in the form: 
yyyy mm dd hh mm iss} 


The time is repeated back in English, in the form "Monday, 
November 15 1982". If the bootload memory is a SCU, the operator 
is invited to type “yes" to set this time (when the time is met}, 
er "no" to enter another time. The time is set in all the 
configured memories, to support future jumping clock error 
recovery. Gn 6000 SC's, the program translates times toa SC 
switch settings. The program gives the operator time to set the 
clock by waiting for an input line. At any time, the operator 
may enter "abort", realizing that something is wrong. 
init clocks then returns. real_initializer will re-enter the 
early command level in this case. 


init early confis.o11 


init_early_config fabricates a config deck based on the 
information available after collection zero has completed. The 
bootload CPU, IGM, console, and tape controller are described. 
The port number of the bootload CPU is not filled in here, since 
it iS not easily determined, Instead, scs_and_clock_initS$early 
fills it in. Appropriate parm, sst, and tcd cards are 
constructed, and placeholders are filled in for the RPV 
subsystem, so that iom_data_init will reserve enough channel 
Slots. init_early_configtdisk is used to fill in the real values 
for the RPV subsystem once they are known. 
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init empty root.pi1 


fill_vol_extents_, the subroutine used by the user ring 
init_vol command, has been adapted to provide the main function 
of this program. It provides a request loop in which the 
operator can specify the number of vtoces, partition layout, etc. 
The operator is provided with a default layout, including the 
usual set of partitions and the default (2.0) average segment 
length. If it is changed, the operator is required to define at 
least the hardcore and bce required partitions and (for the 
moment) the bos partition. 


init he part.pil 


. init _hc_part builds the appropriate entries so that paging 
and allocation may be done against the hardcore partition. It 
builds a pseudo volmap (volmap_abs_seg) describing the hardcore 
partition (which is withdrawn fram the beginning thereof) 
allowing withdrawing of pages from the partition. A record stock 
is also created of appropriate size for the partitions. 


init partitions. pl] 


This program makes sure that the partitions the operator 
specified in the config deck are really there. It checks the 
labels of the config deck specified disks for the specified 
partitions. Disks that do have partitions so listed are listed 
as un-demountable in their pvt entries, 


a t.pll 


The pvt contains relatively static data about each disk 
drive (as opposed to dynamic information such as whether i/o is 
in progress). init_pvt sets each entry to describe a disk. No 
ifo is done at this time so logical volume information, etc. can 
not be filled in. Each disk is presumed to be a storage system 
disk, until otherwise determined later. 


init root vols, pill 


init_root_vols finds the disks that will be used for 
hardcore partitions. It mostly finds the disks from root cards 
and finds the hardcore partitions from the labels. For the rpv, 
it will alse call initlempty_root, if a cold boot is desired, 


call create_rpv_partition, if various required partitions are 
missing (MR11 automatic upgrade), and set various pvt entries to 
describe the rpv. During the service pass, init_hc_part is 


called to establish paging (and allow withdrawing) against the 
hardcore partition, 
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init t_scu.pll 


This routine is used within scas_init to init a given scu. 
It compares the scu configuration information (from its switches) 
with the supplied size and requirements. When called for 
bootload Multics purposes, the size of the scu may be larger than 
that specified (generated) in the config deck without a warning 
message. It generates ptws so it can address the scu registers 
(see the description in the glossary for the scas). The execute 
interrupt mask assignment and mask/port assignment on the 
memories is checked here. 


init sst.plil 


init_sst starts by determining the size of the pools. 
Nermally, this is found in the sst config card (although init_sst 
will generate one of 400 150 50 20 if one isn't found). For 
early and bootload Multics initialization, though, the pools 
sizes are determined from the current requirements given in 
figures in bootload_info. The size of the core_map is determined 
from the amount of configured memory for normal operation and is 
set to describe 512K for early and bootload Multics operation. 
The area for the sst is obtained, either from the top of the 
bootloead scu for normal operation, or fram the silt allocation 
method for early and bootload Multics operation. The headers of 
the sst and core map are filled in. init_aste_pools actually 
threads the astes generated. The pages of memory not used in low 
order (Cor bootload (512k))} memory are added to the core_map as 
free, For normal operation, the other scu's pages are also added 
to the free list. collect_free_core will eventually add the 
various pages of initialization segments that are later deleted. 


init vol header .plt 


init_empty_root uses this program to initialize the rpv. 
This routine writes cut the desired label (which describes the 
partitions filled in by fill_vol_extents_), generates an empty 
volmap and writes it out, and generates empty vtoces and writes 
them out. 


initial error handler .p11 
This any_other handler replaces the fault_vector "“unexpect- 
ed fault” assignments, It implements default_restart and 


quiet_restart semantics for conditions signalled with info, and 
crashes the system for all other circumstances, 
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iwikiat Paul ul 


initialize_faults has two Separate entries, one for setting 
things up for collection 1, and one for collections 2 and beyond. 


This description is for collection 1 
Cinitialize_faultsS$fault_init_one). initialize _ faults_data 
describes which faults have their fault vectors set to 
fimSprimary_fault_entry (scu data to pds$fim_data), 
fimSsignal_entry (scu data to pds$ signal_data), 
fimSonc_start_shut_entry (scu data to pds$fim_data) or 
wired _fimSunexp_fault (scu data to prpds$sys_trouble_data) (all 
others). Speciai cases are: leckup and timer runout faults are 


set to an entry that will effectively ignore them. Dereiis go ts 
fim$dril_entry to handle breakpoints and special dri traps. 
Execute faults are set to wired_fim$Sxec_fault (scu data to 
prdsS$sys_ trouble data). Page faults are set to pagefault$fault 
(scu data to pdsSpage_fault_data). And connect faults are set to 
prdst$fast_connect_code (scu data to prds$fim_data). Write access 
is forced to certain key programs to set values within them. 
Access is reset afterwards. These are pointers which must be 
known by certain programs when there will be no mechanism for the 
programs themselves to find them. An example is the pointers 
within wired_fim specifying where scu data is to be stored. The 
last thing done is to set the signal. and sct_ptr in the 
inzr_stkO stack header so that signalling can occur in collection 
1, 


initialize faults datsa,cds 


This cds segment describes which faults go to where so that 
initialize faults can so set them. For collection 1, the major 
faults set are: command and trouble to fimSprimary_fault_entry 
(scu data in pds$fim_data), access violation, store, mme, fault 
tag 1, 2and 3, derail, illegal procedure, overflow, divide, 
directed faults 0, 2 and 3, mme2, mme3, mme4 to fimSsignal_entry 
(scu. data to pdsS$signal_data), shutdown, op not complete and 
Startup to fim$onc_start_shut_entry (scu data to pdstfim_data) 
and the rest to wired_fimBunexp_fault (scu data to 
prdsSsys_ trouble_data). 


inicialige UW 


initializer consists of only calls to real_initializer, 
delete_segs$delete_segs_init, and init proc. real_initializer is 
the main driver for initialization. It is an init seg. 
initializer exists as a separate program from real_initializer 
because, after the call to delete init segs, there must still be 
a program around that can call init proc. This is the one. 
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The function of this program is to set up the data bases 


used by io_manager. These include jiom_.data and the actual 
mailboxes used in communicating with the iom. The iom cards are 
validated here. The overhead channel mailboxes are set for the 


described channels. 


load disk mpcs pill 


During the "boot" pass, ail disk mpcs must have firmware 
loaded into them. This is done by load _disk mpcs. This program 
scans the config deck, searching for disk mpcs. It tests each 
ene (with he_load_mpc$test_controtler) to determine a list of 
apparently non-loaded disk mpcs. If this list is not empty, it 
prints the list and asks the operator for a sub-set of these to 
load. bce_fwload is used to perform the actual loading. 


load mst.pli 


load_mst reads in the MST. It contains a routine which 
understands the format of a MST. This routine is supplied with 
various entry variables to do the right thing with the cbjects 
read from the various collections. For collection 1.2, the 
objects are placed into the bce file system through bootload_fs_. 
For collection 1.5, the segments have linkages combined, etc. 
just as in segment loader. The objects are placed on disk, in 
locations recorded in a table. These are paged bce programs. 
Collections 2 and 3 are simply read in as is, scrolling down the 
mst area of the "bce" partition using the abs-seg disk_mst_seg. 
The init commands entrypoint uses the table built while reading 
collection 1.5. The appropriate bce segments are mapped onto 
disk using the locations therein. 


make sdw. poll 


make_sdw is the master sdw/aste creation program for 
collection 1 and beyond. It contains many special cases to 
handle the myriad types of segments used and generated in 
initialization. It's first job is to determine the size of the 


desired segment. The size used is the maximum of the site's 
current length, maximum length and the size given on a tbls card 
(if the segment's name is in variable_tables). Also, an extra 
page is added for breakpoints when needed. Given this size, an 
appropriate size aste is found and threaded into the appropriate 
list, either init segs, temp segs, or normal segs. Wired segs 
aren't threaded; they are just tisted as hardcore segments. The 
page table words are initialized to null addresses, If the 
segment is wired and is breakpointable, the last ptw is instead 
S€t to point to breakpoint_pace. For abs-segs, this is the end; 
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abs segs and other "funny" segs must build their own page tables 
and a real sdw to describe them. For a normal segment, however, 
the page table entries are filled as follows: an appropriate 
hardcore partition to hold the pages is chosen. abs_seg's sdw is 
set to indicate this null address page table. The various pages 
are touched, causing page control to be invoked to withdraw an 
appropriate page against the hardcore partition whose drive index 
is in the aste. (abs_seg's Ssdw is then freed.) make_segs_ paged 
and segment_loader, the main clients of make_sdw, will then copy 
the desired data Ceither from wired memory or from the tape) into 
these new (pagable) pages. 


make segs paged pil 


make_segs_paged, that most famous of. initialization pro- 
grams, actually, in a way, has most of its work performed by 
make_sdw. make_segs_paged examines all of the initialization 
segments, looking for those it can page (i.e., not wired, not 
already made paged, non-abs-segs, etc.). It walks down this list 
of segments from the top of memory down, using make_sdw to 
generate an astée, an sdw, and a page table full of disk pages for 
it. The sdw is put into dseg, and the contents of the wired 
segment is copied into the paged version. The pages of memory 
are then added to page control's free pool The dseg is also 
copied with a new dbr generated to describe it. 


Breakpointable segments are special cased in two ways. 
First of all, when the pages of the old segment are freed, 
eccurences of breakpoint_page are not. Also, when copying the 
segment, breakpoints set within it must ke copied. All of 
breakpoint_page cannot be copied since it includes breakpoints in 
other segments. Thus, we must copy each breakpoint, one at a 
time by hand. 


move non perm wired segs .plt 


This program takes the segments allocated high addresses by 
collection OQ (paged segments and init segments that are not 
firmware segments) which were put at the top of the 512K early 
initialization memory, and moves them to the top of the 
contiguousty addressable memory, leaving the top of the low 
controller for the sst_seg and core_map. 


This program depends on the Knowledge that the loader 
assigns segment numbers in monotonically increasing order to 
permanent supervisor and init segs, and that the high segments 
are allocated from the top of memory down. Thus it can move the 
highest segment Cin memory address) first, and so on, by stepping 
along the SLTE's. 
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The copying of the segment can be tricky, though, since not 
only must the contents be moved but the page table must be 
changed to reflect the new location. For this, we build abs_segd 
to point to the new location. The segment is copied into 
abs_seg0. We now make the sdw for the segment equal to that for 
abs_seg)O. The segment is now moved, but we are using the page 
table for abs_segO for it, not the one belonging to it, So, we 
fix up the old page table to point to the new location, and swap 
back the old sdw. This starts using the new ptws in the old 
place. 


Segments that were pbreakpointablte Chad breakpoint_page in 
them) must be special cased not to move the breakpoint page. 


ecdem pit 


Within initialization, the init lall_consoles entrypoint of 
ecdcem_ is called. This entrypoint sets up oc_data to a nice safe 
Cempty) state. The various console specific parms are found and 


saved, The main loop examines all preh opc cards. They are 
validated (and later listed if clst is specified). For each 
console, a console entry is filled describing it. The bootload 
console, when found, is specifically assigned as kbootload con- 


sole. As a last feature, the number of cpus is found. This is 
because the longest lock time (meaningful for determining 
time-outs) is a function of the number of processors that can be 
waiting for an i/o. 


ocdem. also provides for bce a special function. It 
maintains wired_hardcore_datasabort_request, set to true whenever 
the operator hits the request key when this was not solicited (no 
read pending). This fiag is used by bce_check_abort to 
conditionally abort undesired bce operations. 


This program simply initializes certain header variables in 


the prds. This includes inserting the fast_connect_code, the 
processor tag, etc. 


ere link he. pill 

The linker for collection 2, this program performs a 
function analogous to that performed by bootload_linker. It 
walks down the linkage sections of the segments in question, 
looking for links to snap. slt_manager is used to resolve 
references to segments. A definition search is imbeded within 


this program. 
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read disk. pil 


read_disk is the routine used to read a page from or to 
write a page to disk. The init entry point sets up rdisk_seg as 
a one page paged abs segment for such purposes. Actual page 
reading and writing consists of using disk_control to test the 
drive (unless the no_test entrypoints were used), and then page 
control to page the page. For reads, we construct a page table 
word describing the page of disk. Touching rdisk_seg then reads 
it in. For writing, we generate a null address page table entry. 
When we write to it, a page of memory is obtained. By forcing 
the core map entry to describe the desired page of disk, unwiring 
the page and performing a peScleanup (force write), the page 
makes it to disk. 


read disk label.pll 

To read adisk label, we call read_disk_label. It uses 
read_disk to preform the i/o, Several such reads will be 
performed, if necessary. The tabel is validated through a 
simple check of label, Multics, label. version and 


label. time_registered. 


real initializer .pllpmac 


real_initializer is the main driver for initialization. It 
largely just calls other routines to set things up, in the proper 
erder. 


There are many paths through real_initializer as described 
above. Ail paths set an any_other handler of 
initial_error_handler to catch unclaimed signals, which eventual- 
ly causes a crash. 


‘The main path through real_initializer calls collection_1 
(an internal subroutine) multipie times and then passes through 
to collections 2 and 3. Each call to collection_1, in the normal 


case, “increments” sys_infofcollection_1t_phase, thus producing 
the main set of collection 1 passes. Various deviations from 
this exist. Aborting disk mpc loading resets the phase to 
re_early and branches back to the "early" command level. A 
failure when finding the rpv during the “early” pass retries the 
"early" pass. The reinitialize command resets the phase to 


“early” and then simulates the bce "boot" function, thus making 
the next pass become a new "boot" pass. 


When Multics crashes or shuts down, the toehold restores 
the machine conditions of bce saved in the toehold. These return 
the system to save_handler_me, which quickly returns through 
init _toehold to real_initializer. The routine collection_1 
senses this and returns te the main collection_1 calling loop. 
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real_initializer Keys off the memory_state (determines between 
crashing and shutting down) and old _memory_state (state of 
crashed memory - determines crashed collection 1 phase) in the 
toehold to determine the pass to run next. 


real_initializer includes a stop-on-switches facility. 
pli_macro is used to assign 8S unique number to each step in 
initialization. This number can also be used in the future to 
meter initialization. Before each step in initialization, a call 
is made to the internal procedure check_stop. If the switches 
contain "123"b3 11 "“PNNN“b6, where PNNN is the error number in 
binary coded decimati (P is the collection 1 phase, NNN is the 
stop number obtained from a listing), bce is called (if the 
toehold is active). 


scas_init inits the scas (system controller addressing 
segment). It is the Keeper of things cpu and scu. The config 
deck is searched for cpu and mem cards which are validated and 
the boxes' switches validated against the cards. The scstcow 
(connect operand words) are filled in here with values so that we 
may send connects to the various processors. init_scu is called 
to set masks and such for the various scus. The port enables are 
set for the  ioms. The cpu system controller masks are checked, 
Finally, if the cpus and ioms do not overlap in port numbers, the 
cyclic priority switches are set on the scus. 


scs and clock init.pl] 


This program initializes most of the data in the secs. In 
previous systems, the scs was mostly filled in its cds source. 
To Support multiple initializations, though, the segment must be 
reset for each pass. This program also has _ the task. of setting. 
syS_infoS$clock_ to point to the bootload SCU. Finally, at its 


$early entrypoint, it fills in the bootload SCU memory port 
number in the config deck, Since it used that data in scs 
initialization. Initializing the scs consists of initiating data 


about cpus and scus. 


seoment loader .plt 


segment_loader is used to load collections 2.0 and beyond. 
It uses disk_reader to read records from the MST of disk. The 
various records from the MST are either collection marks, header 
records (denoting a segment) or the data forming the segments. 


Given information in the segment header, an appropriately sized 
area in wi_linkage$, ws_linkage$, ai_linkageS or as_linkaget is 
generated. slt_manager$build_entry chooses the next segment 


number (either supervisor of initialization) for the segment and 
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creates the silt entry. make_sdw creates an sdw an the page table 
and allocates disk space in the hardcore partition for the 


segment. With read/write access forced for this new Cpagable) 
segment, the segment is read from disk. Access is then set as 
desired in the header record. We loop in this manner until we 


encounter a collection mark when we Stop. 


Slt _manaser.pi1 

This is a relatively simple program. 
slt_managerSbuiid_entry looks at the header read from an MST and 
builds a slit entry. The header defines whether this isa 


supervisor or an initialization segment (which defines from which 
set of segment numbers (supervisory start at 0, initialization 
start at 400 octal) it is given), what names to add to the name. 
table, and whether this segment has a pathname which needs to be 
added to the name table (so that init_branches can thread them 
into the hierarchy). While it is building the entry, it hashes 
the names in the same manner as bootload_slt_manager. 

slt_manager$get_seg_ptr uses this hash list to search for the 
segment name requested. 


sys info. cds 


sys_info is described under data bases. 


tape reader pl 


tape_reader uses boot_tape_io to read MST tape records. It 
is capable of reading several tape records and packing them into 
a user supplied buffer. It validates the tape records it reads 
for Multics-ness, performing the (old) reading re-written record 
error recovery mechanism. . 


te _ init.p11 

tc_init is run in two parts, the second called part_2 run 
in collection 2. Part one, just called tec_init, allocates an 
appropriately sized te_data {see the description of 
tc_data_header, above) given the supplied number of aptes and itt 
entries, The workclass entries are initialized to their 
defaults. Workclass 0 is set up for the initializer as realtime, 
etc, Everyone else is put initially into workclass 1. The aptes 
and itts are threaded into empty lists. Initial scheduling 
parameters are obtained from the schd card. The length of the 
prds is set (sither default or from thls card). The stack_O_data 


segment (which Keeps track of the ring O stacks’ given to 
processes when they gain eligibility) is initialized. Apte 
entries for the initializer and idie Cbootload cpu) are created. 
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Finally, memory is allocated for the pds and dseg of the various 
idle processes (which won't actually be started until 
tc_initSpart_2). 
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SECTION 4 


THE BOOTLOGAD COMMAND ENVIRONMENT 


Bootload Multics must provide a certain number of 
facilities when the storage system is not available. Examples 
are system dumps to disk, disk saves and restores , interactive 
hardcore debug (patch and dump), and automatic crash recovery. 


INITIALIZATION 


There are two ways that the command environment is entered. 
When an existing system is booted from power-up (cool boot), the 
command environment is entered to allow config deck maintenance 
and the tlike. When the service system crashes, the command 
environment becomes the crash recovery environment that oversees 
dumping and automatic restart. A full cold boot is a special 
case of a cool boot. 


The heart of the bootload Multics command environment (bce) 
runs mostly wired. Tne paged segments are paged temp segments, 
managed by get_temp_segment_ and friends, for such purposes as 
qedx buffers and active function expansion. The bce file system 
is paged, Also, some bce command programs are paged, through the 
grace of load_mst. These are mapped onto an area of the bce 
partition. bce does not use the storage system, nor the hardcore 
partition. 


Certain special programs are run so as to initialize bce. 
These are: init_bce to enable the basic facilities of switches 
and areas and such; find _file_partition to enable the bootload 
Multics file system; establish _temp_segs to provide paged temp 
segments; and, load_mstSinit_commands to allow references to 
paged bce programs. load_mst was described under the bootload 
Multics initialization pass in collection 1. 


ENVIRONMENT AND FACILITIES 


The basic faciiities of the command environment are: 
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a free area. free_area_1 is initialized with define_area_, 
and a pointer left in stack header. user_free_area and 
stack_header. system_free_area, so that allocate statements 
with no "in" qualifiers work. get_system_free_area_ () will 
return a pcinter to this area. This area is used for global 
data needed between commands. Each command normally finds 
its own local area, normally on a paged temp segment. 


Standard input, eutput and error entries that hide the 
distinction between console and "exec_com" input. These are 
entry variables in the cds program bce_data.cds. They are 
hardly ever calied directtiy, as more sophisticated 
interfaces are defined atop them. The entry variables are 
bce_datasSget_line, bce_data$put_chars and 
bce_datatserror_put_chars. get_chars is not sensible in the 
console environment, for the console will not transmit a 
partial line. The module bpce_console_io is the usual target 
ef the entry variables. It uses ocdcm_, o¢_trans_input_ and 
oc_trans_output_. bce_data also contains the pointers 
get_line_data_ptr, put_chars_data_ptr and 
error_put_chars_data_ptr which point to control information 
needed by the target of the entry variable. The pair of 
values of an entry variable followed by the data pointer is 
what constitutes e bce switch. A pointer to this switch is 
passed around much as an iiocbh pointer is passed around in 
Multics. Both ioca_ and formline_ understand these bce 
switches so that normal calls may be made. 


bce query and bkbce_querySyes_no. Each takes a response 
argument, ioa_ control string, and arguments, and asks the 
question on the console, An active function interface is 
provided. 


bce_error is the local surrogate for comlerr_, used by 
various non command level programs. It does not signal any 
conditions in its current. implementation. com_err_. and 


active_fnc_err_ simply call bce_error appropriately when in 
bce, 


a command processor, The standard command_processor_ is 
used to provide a ssu_-like subsystem facility. The various 
command programs are calted with a pointer to 


bce_subsystem_info_, of which the arg_list_ptr is the impor- 
tant information. 


a request line processor. Any program that wants to parse 
lines using standard syntax (without quotes, parentheses, or 
active functions, for now) calls bce_command_processor_ with 
the command line, a procedure that will find the command, 
and a return code. find_rpv_ subsystem, for example, calls 
it with an internal procedure that checks that the command 
is either "rpv", "cold", “help”, or “7", and returns the 
appropriate internal procedure to process the command. 
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These procedures use the usual cu. entrypoints to access 
their arguments. 


The paged temp segments bootload_temp_1 .. boot load_temp_N. 
These are each of 128/N pages long, and mapped as abs-seg's 
ento a part of the bce partition. N is established by the 
number of such segments listed in the MST header (and 
computed by establish _temp_segs). These segments are 
managed by get_temp_segments_ and friends. 


A primitive file system. bootload_fs_ manages a simple file 
system mapped onto the "“fiie”" partition on the rpv. This 
file system can hold config files or exec coms. It is 
writable from within Multics service. The objects in the 
file system have a max length of 128/N pages, matching that 
of the temp segments, and have a single name. ; 


The standard active function set. 


Disk ifo facilities. Several exist. Some utilities call 
(read write) disk. If they do not need the disk test that 
this routine performs (as when accessing the (already) 
trusted rpv), they call the no_test versions of these 
entrypoints. Anether mechanism is to build a paged segment 
onto the desired disk area, normally via map_onto_disk. 
This mechanism trusts the built in mechanisms of page 
control (Cand traffic scontrel disk polling) to ensure that 


the i/o is . noticed. A final mechanism is to call 
dctl$bootload_(read write), which allows the queueing of 
multiple i/os to different disks. This is used for high 


volume operations, such as pack copying. 


TI6 


Various Multics facilties are not present within. bce... Some. 


are listed below. 


* 


No operations upon the file system hierarchy are allowed 
(except for indirect references by bce_probe to segments in 
the Multics image). 


Normal segment truncation/deletion/creation is not allowed. 
The ptws must be manually freed. 


Segments may not be grown (no withdrawing of pages is 
allowed). They must be explicitly mapped onto the desired 
free area of disk or memory. 


No iox_ operations are allowed. Pseudo-iocb's do exist, 
though. 
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* GSniy a finite Cand small) number of paged/wired work areas 
can exist. They also have comparatively small lengths. 


* Dynamic linking is not done. References to object names are 
done with slt_managerSget_seg_ptr. 


* Wakeups and waiting for wakeups can not be done. A program 
must loop waiting for status or use pxss facilities. 


% Timers (cput and alrm) may not be set, Programs must loop 
waiting for the time. 


* There arene ips signals se no masking is involved. The 
real question is the masking of interrupts (pmut$set_mask). 


* Any routine that itself, or through a subsidiary routine, 
calls bce_check_abort (which includes any output operation), 
must be prepared to be aborted at these times. Thus, they 

must have a pending cleanup handler at these times, or 
simply have nothing that needs to be cleaned up. 


MODULE DESCRIPTIONS 


bce abs sea.pl) 
This relatively uninteresting program maintains a list of 
abs-segs built during an initialization pass. This is done so 


that real_initializer can free them, en masse, when it needs to 
reinitialize before another pass. 


bce alert pli 


Console alert messages (mostly for .bce exec.com's) are 


produced by bce_alert. It simply appends its arquments, 
separated by a space) into one string which it prints through 
bce_datatconsole_alert_put_chars. This prints the message with 


audible alarm. 


bce alm die.alm 

bce_alm_die wipes out the bce tochold and enters a "dis" 
state. 
bce appending simulation. pli 

All references to absolute and virtual addresses within the 


saved Multics image are performed by bce_appending_simulation. 
It has multiple entrypoints for its functions. 
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The "init" entrypoint must be called before all others. It 
initializes certain purely internal variables, for later effi- 
ciency. As an added bonus, it sets the initial dbr for the 
appending simulation based on whether it is desired to examine 
the crash image or bce itself. 


The entrypoint “new _dbr” sets a new dbr for the simulation. 
This entrypoint takes apart the dbr supplied. The main purpose 
ef this entrypoint is to find this new address space's dseg, so 
it can evaluate virtual addresses. This fetching of the descrip- 
tion Caste/page table/sdw) of dseg can be done using the absolute 
fetching routines of bce_appending_simuisation and by manually 
disecting sdws and otws. This entrypocint must eliso find the 
core_map, if present, which is needed by the virtual entrypoints 
to find out-of-service pages. 


The "C€get put)_Cabsolute virtual)" address entrypoints 
actually perform the fetching or patching of data. They take the 
input address and fetch or replace data in pieces, keeping each 
piece within a page. This is done because different pages 
desired may reside in totally different locations. 


"get_absolute” and “put_absolute" work in relatively simple 
ways. They examine the address to determine its location. Some 
low memory pages will be in the image on disk and fetched through 
the paged abs-segs multics_(Clow high}_mem. Gther pages are in 
memory Cabove 512k). These are fetched through the abs-seg 
abs_segO which this program slides onto a 256k block as needed, 
References to absolute locations in examine-bce mode always use 
the abs_segO approach to fetch everything from memory. These 
entries keep a page_fault_error handler to catch disk errors, a 
store handler to handle memory addreses not enabled at the 
processor ports and an op_not_complete handler to catch refernces 
to scu’s who have our processor disabled, 


Before virtual addresses may be fetched/patched, the 


“new_segment" entrypoint must be called. The purpose of this 
entrypoint is to fetch the sdw/aste/page table for the segment 
for later ease of reference. This is done by using the 


"get_virtual" entrypoint, referencing dseg data given the previ- 
ously discovered description of dseg (Cin the "new _dbr" 
entrypoint). For efficiency in fetching the sdw (meaningful for 
the dump command which calls this entrypoint for every segment 
number valid in a process and ends up fetching null sdws), a dseg 
page is kept internal to this routine. 


Virtual addresses are manipulated by the "(get 
put)_virtual" entrypoints. These entrypoints break apart the 
request into blocks that fit into pages. For each page of the 
segment that it needs, it examines its ptw (found in the segment 
description found and provided by the "new_segment" entrypoint) 
to determine its location. Pages flagged as in memory are 
obtained by the absolute entrypcint. Pages on disk can be easily 
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manipulated by mapping rdisk_seg onto the page and paging it. lf 
it is in neither catagories, something is either wrong or the 
page is out of service. For out of service pages (pages with i/o 
in progress upon them), the "correct" page is found (the page at 
the source of the i/o) and this manipulated. If this is a put 
operation, it is necessary to replace this page in both locations 
(both memory and the disk page in use) to make sure that the 
effect is felt. Also, for any put operation, the proper page 
table word must have its modified bit set se page control notices 
the modification. 


bce check abort. oll 

bce_check_abort contains the loegic for possibly aborting 
bce functions upon operator request. When called, it checks 
wired_hardcore_datatabort_request, which is set by ocdcem_ whenev- 
er an unsolicited request is hit. If this bit is set, 


bece_check_abort prompts the operator with “Abort?” to which the 
response determines the degree of abort. Both this query and the 
response i/o are performed through bce_dataSconsele_[whatever] to 
force them to appear on the console. A response of "no" simply 
returns. "yes" and "request" signals sub_request_abort_, which 
is intercepted by the bce_exec_com_. and bce_listen_, or by a bce 
subsystem. Entering “command” signals request_abort_, handied by 
bce_exec_com_ and bce_listen_ to abort a subsystem. Entering 
"all" performs a non-local goto to <sub-sys info>.abort_label, 
which returns to bce_listen, at top level. 


bce_check_abort is called on the output side of 
bce_console_io and other output oriented bce i/o modules. Thus, 
most operations will notice quickly the operator's intent to 


abort. However, any program that can enter an infinite 
computational loop (such as the exex_com processor trying to 


follow an infinite &goto ah & label loop) must call 
bce_check_abort within the loop to provide a way out. 


bce command processor pl) 

This routine is a scaled down version of 
command_processor_. It dees not support active functions or 
iteration sets. Written as such, it does not need the various 
werk areas that command_processor_ needs and can run completely 
wired. It separates the command line into the usual tokens, 
forming an argument list of the various argument strings. It 
uses a routine supplied in its call to find an entry variable to 
perform the command = found. It is used in various very early 


initialization programs like init clocks and find _rpv_subsystem 
(which obviously cannot page) as well as some bootload Multics 
programs that can deal with the simplicity and wish not to power 
up command_processor_. 
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bce console jic.pll 


bce_console_io is the interface to the console dim ocdem_. 
Its function is to perform translation appropriate to the console 
Coc_trans_input_ and oc_trans_output_) and to call 
ocdcm_Spriority_io to perform the i/o. bce_console_ioSget_line 
is the routine normally found in the entry variable 
bce_data$get_line and bce_console_ioSput_chars is the routine 
normally found in bce_datas$put_chars and 
bce_datagerror_put_chars. 


bce continue 11 


bce_continue restarts the interrupted image. It flushes 
memory and uses pmutSspecial_bce_return to invoke the tochold, 
As it passes, it resets all rtb flags in the flagbox except 
ssenb. This is so that the next return to bce does not show the 
current rtb flags. 


Also present in this module is the bos command, which 
flushes memory and uses pmutSspecial_bce_return to invoke the BOS 
tochold. 


bce data.cds 

This cds segment contains data pertinent to the command 
environment activities of bce. It holds the entry and data 
pointers used to perform ifo on the pseudo switches 
bce_datatget_line, bce_dataS$put_chars, bce_dataserror_put_chars 
and bce_datatexec_com_get_ line. It Keeps track of the current 
exec_com level, through bce_dataScommand_abs_data_ptr (part of 
the exec_com_get_line switch). It also holds the top level 


subsystem info for the command level in bce_data$subsys_info_ptr. 


bce die.pll 


This module just checks to see if it is okay to die, which 
is actually performed by bce_alm_die. 


bce display instruction .pll 


Gne of the bce_probe support utilities, 
bce_display_instruction_ displays one (possibly multi-word) 
instruction. It uses op_mnemenic_ for its information. The 


result is to print an instruction and to return the number of 
words dumped. 
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bce display scu_ pil 


bce_display_scu_ is another bce_probe utility. It displays 
the scu data found in machine conditions supplied to it. 
bce_display_instruction_ is used to interpret the instruction 


words from the data. 


bce dump. p11 


The disk dumping facility of bce is found in bce_dump. It 
is actually a rather simple program but with a few tricky special 
decisions made within it. After parsing the ccmmand line 
arguments, it figures out the process and segment options to use. 
These options are merged together in a hierarchical fashion; that 
is, options applying to all processes apply to eligible; all that 
apply to elgible apply to running, etc. The dump header is 
filled in with machine state information from the toehold. The 
dump header on disk is flagged as invalid. An abs-seg (dump_seg, 
created by establish_temp_segs) is built to run down the dump 
partition during segment placing. Given this out of the way, 


dumping can start. Each apte is read from the saved image 
(through bce_appending_simulatian). For each, the segment 
eptions applying to each are determined. Given the segment 


limits in the dbr for this process, each segment is examined to 
see if it meets the segment options. Mest of the options are 
self-explanatory. When it comes to dumping non-hardcore seg- 
ments, theugh, it is desired to dump any hierarchy segment only 
once. This is done by keeping a pseudo bit-map of the sst, where 
each bit says that a segment has been dumped. (Since the 
smallest possible aste in the sst is 16 words, there can be at 
most 256K/16 astes. Given an address within the sst from a 
segments’ sdw, we assume that any aste that crosses the mod 16 
boundary near this address describes the same segment as this and 
need not be dumped again. 3 If a segment is to be dumped, we read 
pages from its end, looking for the first non-null page. Ald 
pages from the beginning of the segment up to and including this 
page are appended to the dump. (The dump_seg abs-seg is adjusted 
to indicate these pages.) When all is dumped, we update the 
header and write it out. 


bee error pil 


A simplified form of com_err_, bce_error simply fetches the 
text of an error message from error_table_ and constructs an 
ercor message which is printed through bce_dataterror _put_chars. 
The com_err entrypoint is used to format a com_err_ style 
message, used by com_err_ when called during initialization. 
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bce esd. pil 


An emergency shutdown of Multics is initiated by bce_esd. 
It uses bee_continue to invoke the toehold to restart the image. 
Hewever, before doing this, it patches the machine conditions in 
the toehold to force the image to transfer to 
emergency_shutdownlO, to perform an esd, 


bce exec com .pll 


bee_exec_com_, along witn bce_exec_com_input, form the bce 


eauivalent of version 1 exec _cam's. bce exec _com_ is a merging 
of functions found in exec_com with those found in 
abs_io_Sattach, It finds the ec and builds an appropriate 


ec_info and abs_data structure to describe it. The ec attachment 
is made (bce_datatexec_com_get_line) is made to refer to this ec 


invocation, after saving the previous level. Commands are read 
from the ec through bce_exec_com_input and executed through 
command_processor_Ssubsys_execute_lLine. Once bce_exec_com_info 


returns a code for end of file, the ec attachment is reverted. 


bee exec com input.o11 

bce_exec_com_input performs the parsing of exec_coms. It 
is a pseudo i/o module, in the style of bce_console_ioS$get_line. 
It is called in two possible cases. The first is to fetch a 
command line for execution by bce_exec_com_. In this case, the 


switch is bce_datatexec_com_get_line. When an Sattach appears in 
an ec, bce_exec_com_input will have attached itself (by making 
bce_data$get_line point to itself) and then calls to 
bce_datasget_line will call bce_exec_com_input for a line where 
the switch (bce_data$get_line) will point to the abs_data for the 
ec that performed the &attach. The basic code is stolen from 
abs_io_vi_get_line_. The major changes are. to delete 
non-meaningful operations like &ec_dir. 


bee execute command .p1) 

This routine is the caller for the various bce command 
programs. It is passed as an argument to, and is called, from 
command _processor_Ssubsys_execute_line. It is given a pointer to 


an argument list generated by command _processor_, as well as the 
request name. bce_execute_command,_ uses bce_map_over_requests_ 


to scan through bce_request_table_ to find the entry to call. It 
understands the difference in calling between Multics routines 
(like active functions stolen from Multics) and bce routines. It 


also understands the flags indicating within which command levels 
a command is valid. 


4-3 AN70-01 


bce oad. pl 


Firmware is leaded into various mpcs by bce_fwload. Its 
objective is to find, for each mpc desired, the set of firmware 
images needed for it. hc_load_mpc does the actual loading. For 
a normal (Cdisk, tape) mpc, this involves just finding the mpc 


card which shows the model. The model implies the firmware 
module needed (config_data_Smpc_x_names. fw_tag). The desired 
moduite is found through slt_manager. (Firmware images for disk 


were part of collection 1 and are wired {they needed to be in 
memory to be able to load the rpv controller); other images were 
part of paged collection 1.5.3 For urc controllers, the main 
firmware can also be derived frem the mpc's mpc card. Hscwever, 
it is necessary to check all prpeh cards to find peripherals 
accessible through that urc. For each, and depending on the urc 
channel it is attached to, the appropriate firmware overlay is 
found and put in the correct slot in the list of firmware to 
load, 


bee get flagcbox.pli 


This module performs the bce (get set)_flagbox 
commands/active functions. It is basically aversion of the 
corresponding Multics routine, modified to make direct references 
to the flagbox instead of a gated access. 


bce get to command level, pil 


The routine to get from real_initializer into command level 
is bee_get_to_command_level. It builds a bce_subsystem_info_ 
structure which it passes to bce_listen_. It examines the 
current state to determine if the initial command should be null 
(manual entry), the flagbox bce command (normal) or probe 
(breakpoint entry). Since it. is the routine below 
real_initializer on the stack, it is the routine to which control 
must return so that real_initializer can be returned to to 
perform boot and re_initialize functions. Thus, boot and 
re_initialize are entrypoints within this program. re_initialize 
just returns, setting the collection_l_phase to "early" so that 
real_initializer will end up running another boot pass. This 
will cause bootload Multics to pick up any changes that have been 


made to the config_deck. boot scans the arguments which are 
inserted into the intk card. It then returns. 


Another bce_probe utility. This routine is used to deter- 
mine the length of an instruction, so that it may be correctly 
relocated, It differs from the real probe's version in that it 
does not attempt to deal with xec instructions. 
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bce List requests .pl 


This program implements the list_requests {1r) bootload 
Multics command. It does a simple minded walk down the bootload 
Multics request table, using bce_map_over_requests_, with a 
printing routine to print the request names and the description 
within the table. It understands the dont_list flag, as well as 
understanding flags indicating at which levels a given command is 
valid. 


bee listen .pli 


bce_listen is a simple loop that reads a command line from 
bce_data$get_line and executes it through command _processor_ 
(using bce_execute_command_ to actually execute the request). It 
contains the sub_request_abort_ and request_abort_ handlers to 
work with the operation of bce_check_abort. 


bce map over requests .p1] 


Programs that wish to walk down the boottoad Multics 
request table (bce_list_requests_ and bce_execute_command_) call 
bce_map_over_requests_ with a routine that is called on each 
entry in the table. As such, the format of the table itself is 
known only to this routine. 


bce name to sesnum pit 


This bce_probe utility maps segment numbers to names. It 
searches the sit and name_tables from the saved image. 
Entrypoints exists to convert a segment number to a hardcore 
segment name (bce_segnum_to_name_), a segment pointer to a 
virtual name (Cbhce_segptr_to_name_), and. a segment. .name .to a 
segment number (bce_name_to_segnum_). 


bce probe. pil pmac 


The main portion of bce's probe support, bce_probe contains 
the main drivers for most of probe's facilities. It contains the 
request line parser, address and value parsers and most of the 
functional routines. 


bce_probe starts by examining its arguments and its envi- 
ronment to determine its operating mode. It defaults to 
examining the breakpoint image if the flagbox indicates a bresk, 
to examining the crash image, when at bce_crash or crash command 
levels or to examining bce otherwise. Given its operating mode, 
it initializes the appending simulation package accordingly and 
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establishes a few initial constants. If in break mode, it 
determines the point of break for operator information. 


bce proceeds to read request lines from the console. The 


first "string" in the line (or partial line left, if this is a 
multiple request line) found by internal routine get_string 
becomes the request name. This is looked up ina table and 


dispatched through a "case" statement. 


REQUEST ROUTINES 


The before request finds the desired address. It is 
validated to ensure that it is virtual and that the segment named 
is breakpointable. Finding the breakpoint page for this segment, 


this request looks for an empty break = slot. The original 
instruction is relocated there (bce_relocate_instruction_) and 
replaced by a transfer to the break block, The break block 
consists of a"“drl -1" instruction, which causes the break, 


followed by the relocated instruction, followed by a transfer 
back to just after the original instruction in the code. This 
break block and the transfer to the block are patched into the 
segment such that failure at any time will not damage the 
segment. 


The continue request validates itself and calls 
bce_continue. 


The dbr request fetches its arguments. Constructing a new 
dor, it calls internal routine new_dbr. 


The display request gets and validates its arguments. It 
loops, fetching (through bce_probe_fetch_) at most a page ata 
time to display (since we oniy allocate a one page buffer for the 
fetch). The internal routine “display” displays the data in the 
specified mode. Since data to be displayed may cross page 
boundaries, any data "display" cannot display (because it would 
need data from the next page to fill out a line) is "scrolled" in 
front of the page buffer and a new page worth's of data fetched. 
This continues until the last page is fetched. 


The tet request finds the address and sets up for patching 
of same, It then loops, finding values from the request line, 
converting them to binary. These are appended unto a word based 
buffer, When all are fetched, they are patched into place. 


The list_requests request simple prints a canned list of 
requests, 


The mc request gets its address and uses bce_display_scu_. 


The name request uses bce_segnum_to_name_. 
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The proc request fetches the desired apte from tc_data in 
the image. A new dbr value found therein is passed to internal 
reutine "new_dbr". 


The quit request quits. 


The reset request performs the inverse of the before 
request. After validating its address (for virtualness, 
breakpointability, etc. ), it undoes the effect of before, in 
reverse order to prevent damage to the segment. 


The segne request uses pce_name_to_segnum_. 


The stack request validates its argument. Given the word 
offset therein, it decides whether to start from the specified 
stack header or frame. The needed data is fetched and displayed 
in interpreted form. Each stack pointer fetched is validated, 
not only to insure that it is a valid pointer, but to insure that 
stack frame loops do not cause bce probe loops. 


The status request uses the internal routine "status" to 
display breakpoints set. It simply validates its argument and 
decides between listing breakpoints for a segment versus listing 
breakpointed segments. 


INTERNAL ROUTINES 


check_no_more_args insures that no more arguments appear on 
the request line; that is, that we are looking at a semi-colon or 
new- line. 


display displays data in a specified mode. It determines 
the bit sizes to display, alignments, etc. Its only trick is 
when processing the end of a buffer full that .doesn't fill a 
display line. This causes it to not finish its display. Its 
caller (the display request) then appends what was not displayed 
to the front of the next buffer full so that it may appear in the 
next group. 


function is used to parse functional references, such as 
*regqtrair)". function extracts the arguments to the function 
(whose identity was determined by its caller), builds an argument 
list from these strings, and calls the function, 


get_address contains the logic to parse a bce probe 


address, It fills in the structure, bce_probe_datasSaddress to 
define the current address. It special cases the dot (".") 
forms, checks for virtual forms (those with a "JI" in them), 


notices absolute addresses (single octal number} and uses func- 
tion for the pseudo-variable type of addresses (reg and disk). 


4-13 AN70-01 


Internal routines to get_address, called by function, build the 
address structure for these types. 


get_string finds the next "string" in the request line. 
Its basic job is to pass whitespace and find string delimiters. 


get_value finds a let request value. It looks for ascii 
Strings (values starting with a quote character), which it must 
parse separately (since quoted strings confuse the notion of 
string contained in get_string), finds virtual pointers (strings 
containing "I"), and finds the various numeric types. 


1line_error is used to print error messages. Besides 
printing the given message, optionally with or without the 
current request line arg or error code, it also aborts the 
current request line. 


new_dbr is the counterpart to the new_dbr entrypoint to the 
appending package. It exists to set up references to a few 
popular segments (slt and name_table) whenever the dbr changes. 


pass_white passes whitespace. 


status displays breakpoint status. Since break blocks are 
zeroed when not in use it is possible to find them easily. For 
any segment listed in the image’s silt as being breakpointable, 
status fetches the last page (that which holds the breakpoints) 
and examines each break block. Any with a valid 
original_instr_ptr are displayed. 


bce _ probe data, cds 

Information communicated between probe and its support 
routines is done so through bce_probe_data. This cds contains 
the current value of "." (current address), as well as pointers 


to bce_appending_seg_info structures describing key segments in 
the image used by the support routines. 


bce probe fetch .pil 


This support utility to bce_probe fetches data, given a 
length and the current address (in bce_probe_data$address)., It 
simply uses bce_appending_simulation for absolute and virtual 
address and read_disk for disk addresses, Register addresses 
must be specially handled by the caller. 


bee guery pil 


bce_query is a simple-minded counterpart to command_query_. 
It uses bce_datatput_chars to print a question and 
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bce_data$get_line to read an answer. The main entrypoint accepts 
any answer and bce_query$yes_no accepts only yes or no which it 
returns as a bit. This routine is catled with no prompt by some 
routines who find its return result (char (*)) to be better that 
the buffer and length and return length returned by 
bce_dataSget_line. 


bce ready.pll 
bce_ready prints the bce ready message: 
bce (BCE_COMMAND_LEVEL) TIME: 
It has a nnl entrypoint to print the message without new-line (as 


a prompt), The nermal entry prints the line (for ready message 
within exec_com). 


bse relocate instruction .ptl 


This is another support routine for bce_probe. It differs 
from the standard Multics version in that it does not allow 
relocation of "xec" instructions. {Service probe allows this by 


attempting to examine the target of the xec, something bce_probe 
does not attempt. ) 


bce request table .aim 


The bootload Multics request table is a normal ssu_ request 
table built with ssu_request_macros. Each entry contains a 
pointer to the routine that performs a request, the name and 
shert name of the request, and a short description of the 
request. The actual threading of the entries is Known only to 
bce_map_over_requests_, which performs the walking .down of this 
table. The last three flags in each raq.data entry is used to 
specify whether the command is valid at the three main bce 
command level types: early, boot and crash. 


bce severity pil 


This is the bce counterpart to the Multics severity 
command/active function, It does not work as the Multics routine 
does, however, Instead, it Knows the set of programs that 
recognize a severity indicator. For the desired one, it calls 
the severity entrypoint thereof to find the severity. 
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bce _ shutdown state pil 


The current shutdown state of the storage system (rpv 
label. shutdown_ state) is found by this routine. It uses 
read_disk to find this information. 


bce state .pll 


This command/active function simply returns the name of the 
current bce state. 


bootload disk pest. plt 


. This routine is used in conjunction with the high volume 
disk facility of bce (detl$Sbootload_(read write)). Whenever a 
disk i/o queued through this means is posted for completion, it 
is done so through bootload_disk_post, called by either dctl or 


disk_control. The result is posted in a structure described by 
boot load _post_area. incl.pll. This area must be maintained by the 
caller. 


bootload fs .pil 


bootload_fs_ contains various routines to act upon the 
kbootload Multics file system. The format of the bootload Multics 
file system is Known only to this program. The file system is 
kept in a single abs-seg (bootload_file_partition), mapped Cand 
paged) off the bce partition on the rpv. A two page header at 
the start of the partition contains a directory of 174 entries 
(max that fits) listing the name, size and placement of the file 
within the segment. Also present is a free block map. Files are 
allocated as a contiguous series of blocks (64 word blocks) 


within the segment. The segment is . automatically compacted by 
this routine when necessary. Entrypoints to this routine are: 
lookup (find the length of a file given its name), List 


(allocates a list of file names and sizes within a user supplied 
area), get (copies a file into a user supplied buffer), get_ptr 
(returns a pointer and length to a given file (hces_Sinitiate?)), 
put Callocates area within the file system for a file and copies 
a user supplied buffer into it}, put_ptr (allocates an area 
within the file system large enough for a given file and returns 
a pointer to it) (both put and put_ptr take an argument allowing 
for the deletion of afile with the same name as the one 
desired), delete (deletes a directory entry and frees the space 
used), rename (renames a file (does not allow name duplication)), 
and init (clear out the bootload file system entirely). 
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bootload fs cmds .p11 


This program simply calls bootload_fs_ to perform the 
functions of the bootload Multics commands print, list, delete, 
rename, and initialize. This routine supports the star and equal 
conventions for most of its operations through match_star_name_ 
and get_equal_name_. 


boot load gedx oll 


booticad_qedx is a modified version of qgedx. it differs in 
its use of file system operations (bhootload_fs_}) and its use of 
temp segs. 


confisa deck data .cds 


The config deck editor's source of config card descriptions 
is found in config_deck_data_. This cds provides labels for the 
fields, numbers and types of fields, etc. 


confia deck edit .p1t 


This is the program that edits config decks. It calls 
qedx_ to perform text editing, specifying the caller_does_io 
option. With this option, qedx_ calls config deck_edit_ to 
perform read and write operations on buffers. Any read/write not 
to the config deck uses bootload_fs_. Reads/writes to <config 
deck> (buffer 0) use the config deck conversion routines. This 
program makes use of config_deck_parse_, the routine that can 
convert from ascii (possibly labeled) form to and from binary 
form. The conversions are performed using a set of tables 
(config_deck_data_) that describe the names of the fields, the 
required and optional number’ thereof, the data types. of. the... 


fields, etc. Also allowed by the conversion routines are cards 
of types not recognizable starting with a dot ¢(.) which are not 
validated. This is to allow for future expansion and site 


formatted cards. 


When a command line argument is supplied, the file 
specified is accessed (bootload_fs_$get_ptr) and the object 
obtained is supplied to the internal routine write_config._ deck 
which sets this new deck. 


establish temp segs.pll 
Whenever bce needs (paged) temp segments, it calls 
get_temp_segments_. get_temp_segments._ gets these segments from 


the pool of segments bootload_temp_1..N. establish_temp_segs 
divides the temp seg pages allocated in the bce partition (128 
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pages) up into the N segments (N is determined from the number of 
such segments listed in the mst header}. The paged segments are 
built as abs-seg's onto this area of the determined length. This 
size is saved in sys_infotbce_max_seg_size. establish_temp_segs 
also creates the bce segments multics_flow high)_mem, used to 
access the saved image, dump_ seg, used to access the dump 
partition and disk_config_ deck, used to access the rpv (real?) 
copy of the config.deck (as opposed to our running copy in 
config deck). 


find file partition. pli 


find_file_partition maps the bootload Multics file system 
abs-seg (bootload_file_partition) onto the bce partition on the 
rpv in much the same manner as establish_config_deck maps the 
config deck. It also calls bootload_fs_Sinit to begin accessing 
the segment. If bootload_fs_ states that the file system is bad, 
find _file_partition will call bootload_fs_Sinit again, this time 
to clear out the file system. 


init bce pli 

init_bce initializes the bootload Multics command environ- 
ment features required for future programs. It is called early 
in initialization. At its wired entrypoint, it sets up 


free_area_1l as an area, setting the inzr_stkO stack header to 
point to it so that allocates without an area work correctly and 


so that get_system_free_area_ also works. This routine also 
initially sets bce_datasSget_line, bce_datatsput_chars and 
bce_dataterror_put_chars to their appropriate entry values 
(bce_console_ioSget_line, bce _console_ioS$put_chars and 
bce_console_ioSput_chars, respectively) so that calls to 
bce query, bce_error and especially ioa_, will work, At its 


paged entrypoint, it finishes up. references to paged obiects,. in 
particular, to the exec_com routines. 
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SECTION 5 


CRASH HANDLING 


Bootlead Multics must be able to save the salient state of 
a crashing system and set up the command environment for dumping 
and other intervention. 


EARLY CRASHES. 


Crashes in collection 0 or the early initialization pass of 
collection one should be very rare. Since the system uses a 
generated config deck, the set of possible operator inputs is 
small, and it is possible to do amuch more thorough job of 
testing than can be done with BOS or service initialization. 
However, hardware preblems will happen, and software bugs will 
sneak through. To cover these cases, collection O includes a 
crash handler that can write a core image to tape, prompting the 
operator for the drive number. 


THE ISEHOLD 


. The toehold, toehold.alm, is an impure, wired, privileged 
program that resides in a Known location in absolute memory 
(240009). It has entrypoints at the beginning that can be 
entered in one of two ways: with the execute switches processor 
function, or by being copied into the fault vector. The toehold, 
therefore, is entered in absolute mode. It must save the 512K 
memory image off to disk, and then load in the crash handler. 


The memory image includes the complete machine state. All 
absolute addresses, channel programs, port and channel numbers, 
and other configuration dependent information is stored into the 
toehold by a PL/I program, init_toehold.pll. Thus the alm code 
does not have to know how to do any of these things, which 
simplifies it considerably. 


The toehold starts with the various entry sequences: one 


for manual entry, one for Multics entry Cwhich differs from 
manual entry in that the means of entry is to execute the entry 
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through a fault vector entry: it is necessary to update the 
machine conditions in this case to pass the instruction that 
caused the fault vector execution) and one for restarting the 
machine image. The crash entries save the entire machine state. 
This is done under the protection of the memory_state so that the 
machine state is not overwritten if the toehold is invoked again 
after being invoked after a crash. An internal routine performs 
ifo given a set of dew lists (built by init_toehold). After the 
memory is saved and the crash handler read in, the machine state 
of bce is restored. (1% was saved by save_handler_mc.) This 
causes areturn into save_handier_mc, which quickly returns to 
init_toenhoid, which quickly returns to real_initializer who 
quickly starts the appropriate crash initialization pass. 


Gn the restore side, the system is masked and the internal 
routine called to read back the saved image. The machine 


conditions are restored from the toehold (which is not 
saved/restored during the memory shuffle). 


MSDULE DESCRIPTIONS 


fim.alm 


fim is listed in the crashing set of modules in as much as 
that it contains the bce breakpoint handler. A bce breakpoint 


consists of a"drl -1" instruction. fim's drt handler special 
cases these (in ring QO), saves the machine state in 
breakpoint_page (after advancing the ic to pass the dri instruc- 
tion) and calls pmut$bce_and_ return. It also performs the 


restart from a breakpoint. 


init toehoid.pil 


This pli program constructs the channel programs to save 
and restore the 512K memory image, and fills it and other data 
into the text of toehold. After saving the bce image (crash 
handler) on disk, it calls save_handler_mc to save the current 
machine state of bce in the toehold. When bce is invoked upon a 
crash, the bce restore operation will return to the return in 
save_handler_me which will return to this point in init toehold, 
init. toehold notices this and quickly returns to real_initializer 
whe will perform the desired crash initialization pass. 


save handler m¢e.alm 
The save_handler ume program, called from init_toehold right 


after it saves the crash handler to disk, saves in the toehold 
the machine conditions appropriate for bce. Besides register 
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contents and such, it saves the return address to the return in 
save_handler_mc. 
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SECTION 6 


COLLECTION 2 


. The main task of collection 2 is to make the storage system 
accessible. Along its way, it loads collection 3 into the 
storage system and places the appropriate entities from collec- 
tions 1 and 2 into the hierarchy. The sub-tasks are to enable 
segment control and directory control. The real traffic control 
is also started, Since collection 2 runs in a paged environment, 
it does not have the memory restrictions that collection 1 had, 
This is the reason why it is in a different collection from 
collection 1. 


ORDER GF EXECUTION 


The operations performed in collection 2 are described 
below. 


initialize_faults$fault_init_two is called to change the 
fault vectors into the desired values for normal service opera- 
tion, now that the code for such has been loaded, 


Initialization Now runs performing several intermingled 
functions, All hardcore segments must be created now, before 
traffic control is fully initialized. This is so that the 
address space inherited by the new processes (idle in particular) 
encompasses all of hardcore. 


tty_buf, tty_area and tty_tables are generated through a 
call to fnp_init. They won't be needed at this time but must be 
allocated before tc_initSpart_2. 


Unique id (uid) generation is initialized by a call to 
getuidsinit. This tis required before segments in the hierarchy 
Cin particular, >s1l1 and >pdd) can be created. 


init _vtoc_man allocates and initializes the 


vtoc_buffer_seg. We are therefore eligible to read and write 
(and create) vtoces. 
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dem_seg is allocated and initialized to an area by 


dom_manSinit. init_scavenger_data allocates the scavenger_data 
segment, used by the volume scavenger. The page control data 
base, dm_journal_seg_, used to control synchronous page opera- 
tions (data management), is initialized by init_dm_journal_seg. 
dir_lock_seg, used to keep track of directory lockings and 
waitings thereupon, is initialized by dir_lock_init. Again, 


these are created before tc_init$part_2 is run. 


After this psint, changes to the hardcore descriptor 
segment may not be reflected in idle process and hproc descriptor 
segments. This is pecause init _sys_var, which sets various 
system variables, uses the number of supervisor segments present 
(which is the expected total set thereof) to set the stack base 
segment number in various variables and in the dbr. 


We can now run te_init$Spart_2, which creates the idle 
processes and starts multiprogramming. At this time, only the 
hootload cpu will be running but the idle process will be enabled 
to run on it. 


With multiprogramming active, syserr_log_init can create 
the syserr hproc (after it makes the syserr partition accessi- 
ble). We then log a message to the effect that this was done. 


The activation of segment control, which began with the 
creation of the sst, continues now with the creation of the 
system trailer seg (str_seq) by init_str_seg. If the astk (Cast 


track) parm was specified, init_sst_name_seg initializes the 
sst_names_ segment with the names of paged hardcore segments. 


The entrybounds of hardcore gates are set via a call to 
init_hardcore_gates, which also stores linkage pointers into the 
gates for a reason described under the description of the 
program, 


We can finally make the volumes of the erlv accessible for 
storage system activity by a call to accept_rpy. This sets up 
the volume and vtec maps and stocks for the drives, allowing 
vtoc_man and the page creation/destruction functions to work 
against the paging region of the disks. 


The legical volume table (lvt) is initialized to describe 
the riv by init olvt. 


bad_dir_ and seg _fauit_handlers are now set up as we are 
about to access our first directory. init_root_dir makes the 
root directory Known in the Initializer's process, creating it if 
this is a cold boot. The functions performed here are those that 
will allow future hierarchy segment references through segment 
control (kst creation, in particular). Kkst_utilSgarbage_collect 
is called just to make the kKst neat. At this time, we can 
consider segment control to be active. We can call upon it to 
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create, delete or whatever. The presence of the root will allow 
these activities by virtue of the special casing performed by 
segment control when it discovers a segment with no parent (the 
root). 


The hardcore entities which need to be placed into the 
hierarchy (deciduous segments) are done so by init _branches, 
which also creates >s11 and >*pdd appropriately. These entities 
will be needed when we try to leave ring zero, OF course, other 
required segments are needed; these are the contents of collec- 
tion 3. 


init_stack_0 then runs to create the vaerisus stack_O's to 
be shared between eligible processes, now that it has a place to 
put them. 


delete_segs$temp can now run, deleting collection 2 tempo- 
rary segments. This ends collection 2. 


MEDULE DESCRIPTIONS 


accept fs disk .pil 


A disk is accepted into the file system by accept_fs_disk. 
It validates the pvte for the disk. The label is read. (If this 
is apre-MR10 pack, salvage_pvy is called to convert the vtoc 
region for stock operations.) The pvid and lvid of this disk are 
copied into the pvt, finally making this data valid. The votmap 
and vtoc map are initialized and the stocks made active by 
init_volmap_seg. If this fails, the volume salvager is called 
and we try again. The partition map from the label is checked 
against the volmap to make sure that no partition claims pages in 
the paging region. The updated disk label is written out as we 
exit. 


accept rpv.pll 


The volumes of the rlv are accepted for storage system use 
by acceptirpyv. First, the various disks that have hardcore 
partitions are validated, from their labels, to be part of the 
riv, We then scan the intk card to see if the rpv or rlv desire 
Salvaging; these facts are stored in the pvt. If the rpv needs 
Salvaging, this is done now (salvager$volume_salvage). For 
information purposes, we log for print, if the hcpt parm was 
specified), the amount of the hardcore partition used on the 
various disks. accept_fs_disk is called to accept the rpv in the 
normal way. wired shutdewn is enabled as the storage system is 
considered to be enabled. Appropriately, make_sdwsreset_hcp is 
called to prevent further attempts to allocate from the hardcore 
partition, Contrary to the name (Caccept_rpyv}, the entire riv is 
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accepted next by calling the salvager, if necessary, and 
accept_fs_disk for the other riv volumes. We can then clear 
salv_datat$rpv to keep the salvager from salvaging the rpv later. 


create root dir. pill 


During a cold boot, the root is initialized by 
create_root_dir. It locks the root, setting its uid to all ones. 
The various dir header variables are set, pvid, master_dir flag, 
etc. A directory style area is set up along with a directory 


hash table. The dir is then unlocked and we exit. 


create root vtoce.p11 


create_root_vtoce creates a vtoce for the root directory 
during a cold boot. The vtoce created describes the root as a 
master directory of appropriate length, maximum quota Limit, 
created as of the current time, primary name of ">", etc, 
vtoc_man is used to allocate space in the vtoc map for this and 
to write it out. 


dbm_man.pil 


dbm_man manages the dbm_seg (dumper bit map) for the volume 
dumper. The init entrypoint used during initialization allocates 


and initializes the dbm_seg. Its size is determined from the 
number of disk drives configured and allocated out of the 
hardcore partition by make_sdw. This routine changes dbm_seg 


from its MST status (Can abs_seg) to being a real segment. 


The segment used to keep track of directory lockings and 
waitings thereupon, dir_lock_seg, is allocated and initialized by 
dir_lock_inid. The size of this segment is based upon 
max_max_@ligible (the maximum number of readers of a lock) and 
sys_infoSmax_tree_depth (maximum lock depth one can hold). The 
dir_lock_seg is converted from an abs_seg to a real seg, paged 
eut of the hardcore partition. Initially, ten dir_lock's are 
allocated, threaded appropriately. 


fine init.o11 


fnp_init initializes the data bases used in Multics-fnp 
communication. tty_buf is allocated in wired memory either with 
a default size or a size specified by the ttyb parm. Various 
header variables are set up. If a tty trace table is called for 
by a config parm, it is allocated in the tty_buf free_space area, 
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tty_area is initialized as an empty area. tty_tables also has 
its header filled in and its table_area set to an empty area. 
The config file is scanned for fnp cards; each one sets the 
fnp_config_ flags appropriate to it. The hardware fixed 
dn355_mailbox for each fnp is zeroed. fnp_info is set. Finally, 
io_managerSassign is called to assign each fnp with an interrupt 
handler of dn355S$ interrupt. 


getuid.aim 
getuid is the generator of uid's Cunique identifiers) for 
storage system objects. lt operates by effectively incrementing 


tc_datasgid under its own form of lock. The init entrypoint used 
during initialization stores an initial uid "seed" in tc_datatid 
generated from the clock value. 


init branches. pil 


The program that places the appropriate hardcore segments 
into the hierarchy, creating >sl1l and *pdd as it gees, is 
init_branches. To start with a clean slate, it renames the old 
>process_ dir_dir and >pdd to a screech name. append then creates 
@ new process dir_dir (Cadded name of >pdd) which is then 


initiated. The per_process sw is set on for this dir. It is 
given the maximum quota possible. The old >system_library_1 
(>s11) is also renamed and anew one created and initiated, 


Access is set to s for *.*,* on it, We then walk down the 
various sst pools looking for segments to have branches created. 
The sst entry leads us to the silt entry for the segment to be 


placed in the hierarchy. create_branch is called (running 
recursively) to create a branch for the segment (Cit creates all 
necessary containing directories and a vtoce for the segment). A 


pointer to the parent directory and its aste is found. The aste 
for the hardcore segment is. threaded into the parent. entry. - The 
per_process sw, max _ length and uid fields are set in the aste. 
It is then threaded out of the hardcore lists and into the 
appropriate segment list. The vtoc index provided for the 
segment (found in its entry in the parent directory) is copied 
into the aste so vtoc_man will work. The entrybound of the 
segment is placed into the directory entry. If aste tracking is 
going on, a sstnt entry is added. Its vtoce is updated, putting 
the correct information from the initialization created aste into 
the vtoce, The parent directory is then unlocked and terminated. 


The per_process sw is turned on iin the aste for >pdd so 
that it can propogate down to sons activated off it. We walk 
down >pdd to propogate this switch. The maximum length of the 
silt and name_table are explicitly set, not trusting the site 
fields for them. A maximum quota is reset on >pdd. The default 
acl term of sma *.SysDaemon is removed from >pdd and the acl term 
of sma Initializer.SysDeaemon.z is added, >dumps is created and 
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salvaged if needed. The hierarchy is now properly created and 
active. 


init dm journal seqa.plt 


init_.dm_journal_seg initializes the page control data base 
dm_journal_seg_ used to control synchronous page operations. 
This routine parses the dbmj card. This card describes the sizes 
of the various journals needed, Gnce the size of dm journal _seg_ 
is found, its memory (wired) is obtained from make_sdw. Various 
header parameters (pool thresholds, pages heid, events) are 
filled in, The various journal entries have their time stamp 
initialized to tc_datatend_of_time. The various page_entry's are 
threaded into a list. After this, sst$dm_enabled is set for the 
world to know. 


init hardcore gates. pil 


init_hardcore_gates performs a variety of functions to make 
these things which are hardcore gates into future usable 
entities, It recognizes anything in the silt with ring brackets 
of oO, O, n as a hardcore gate. It finds within the text (given 
the definitions) the segdef .my_lp and stores there (having 
forced write access) the linkage pointer for the gate. This is 
dene because, the gate, Known in outer rings by a segment number 
different from the hardcore number, would not be able to find its 
linkage by indexing into the lot by its segment number as normal 
outer ring programs do. Given the seagqdef .tv_end found for the 
gate, the entrybound is set in the gate's sdw. Finally, the ring 
brackets for restart _fault and return_to_ring_O_ are set from 


their sit values so that these segments may be used in outer 


rings with their hardcore segment numbers. (return_to_ring_O_ 
has a pointer to it stored as the return pointer in the stack 
frame by signaller. _return_to_ring_ O=_ . finds... restart_fault 


through a text imbedded pointer.) 


init lvt.pll 
The logical volume table is initialized by init _ivt. It 


sets up the header and then uses logical_volume_managerSadd to 
add the entry for the rlv. 


init processor .aim 


A processor is inited by init_processor. The init 
entrypoint stores the absolute address of various variables into 
init_processor itself for execution within absolute mode when 


started on other cpus. When run to Start a cpu, it performs some 
collection of tests, enters appending mode, fiddies with associa- 


6-6 AN70-0O1 


tive memories and cache, informs pxss that it is running (through 
its apte), initializes pds and prds time values, sends out a 
connect to preempt the processor and then opens the mask to allow 
interrupts. (We will be interrupted at this time (by the connect 
we sent), This will cause us to find our way back to pxss to 
schedule something to run on this processor.) The idle loop for 
@ processor is contained within init processor following this. 
The idle loop flashes a moving pattern in the aq lights when it 
is on the processor. At this time, x4 contains the number of 
eligible processes, ©«5 the term processid and x6 the number of 
ready processes for the sake of checking system operation. 


init root dir. pelt 


The root directory is made known by init_lroot_dir. We 
Start by checking to see if this is a cold boot. If so, 
create_root_vtoce is called. The root vtoce is read. An aste is 
obtained for the root dir (64 pages), which is initialized from 
the data in this vtoce. pe is used to fill the page table. 
search_ast hashes in this aste. We can now begin the process 
that will allow future segment accessing activity through segment 
control. The Initializer's kst is built, by initialize _kst. The 
pathname “associative memory” used to map segment numbers to 
pathnames is initialized by pathname_amS initialize. makeknown_ 
is called to make the root (uid of all ones) known (found in the 
Kst). If this is a cold boot, this segment just made known must 
be initialized to a directory by create_root_dir. Finally, this 
directory is salvaged, if necessary. 


init scavenger data. oli 


The segment scavenger _data is initialized by 
init scavenger_data. 


init sst name seq. pil 


The sst_names_ segment is initialized by init _sst_name_seg 
whenever the astk parm appears. It walks down the slt, looking 
for segments that are paged with page tables in the sst. For 
each, it copies the primary name into the sst_names_ segment. 


init stack O.pii 


The various ring zero stacks (stack_9) are created by 
init _stack_0O. Since a process cannot lose eligibility while in 
ring 9, the number of processes that can have frames down on ring 
zero stacks is equal to the maximum possible number of eligible 
processes (max_max_eligible). We thus create this many ring O 
stacks which are used by eligible processes, The various 
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stack_O.nnn segments are created in >sll. They are, in turn, 
initiated, truncated, and prewithdrawn to be 16k long. The vtoce 
is updated accordingly. The stack header from the initializer's 
ring zero stack is copied into the header of these stacks. The 
stack is then terminated. The acl for Initializer is removed, 
The first stack slot is claimed for the Initializer; the current 
stack being put into the slot in stack_0O_data. 


init str seo. pil 


init_str_seg initializes tne system traiiter segment 
(str_seg) into a list of free trailer entries. 


Now that all of the hardcore segments have either been read 
in or created, we can now stand back and observe hardcore. The 
next supervisor segment number (mod 8) becomes the ring 0 stack 


segment number (stack base) which is stored in 
active_all_rings_data$stack_base_segno and hescnt. We make sure 
that the dsegs for the idle processes will be big enough to 
describe these segments. The stack base is stored in the dbr 
value in the apte. Various other system variables are set: 


sys_infoStime_of_bootload, sst$pvhtp (physical volume held table 
pointer), sst$rqover (record quota overflow error code, which is 
moved to this wired place from the paged error_table_), and 
sst$checksum_filemap (depending on the nock parm). 


init volmap seg.pll 


init_volmap_seg initializes a volmap and vtec map segment 
allowing us to reference such things on a given physical volume. 
It starts by acquiring an aste for the volmap_seg (for. the 
segment abs_seq) and one for the vtec header (for the segment 
volmap_abs_seg) (vtec map) which are then mapped onto the desired 
areas of the disk. (This is done under the ast lock, of course. ) 
The free count of records is redetermined from the volmap. The 
same is done for the vtoc map. If this is a member of the rlv 
and volume’ inconsistencies were previously found and the number 
of free vtoces or records is helow a certain threshold, a volume 


salvage is called for. If we will not salvage, we can accept the 
disk. Use of the hardcore partition on the disk is terminated 
through a call to init _hc_partSterminate_hc_part. Vtoc and 


record stocks are allocated. The pointers in the pvte to these 
stocks are set as are various other status and count fields. The 
number of free records and the base address of the first record 
im each stock page is computed, The dumper bit map from the disk 
is allocated into the dbm_ seg (previously created by 
dbm_man$ init map). Finally, under the ast lock, we clean up the 
abs_seg and volmap_abs_seg segments (free their sdws). 
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init vtoc man.pll 


The vtoc_buffer_seg is initialized by init_vtoc_man. This 
routine acquires enough contiguous memory for the 
vtoc_buffer_seg, determining the number of vtoc buffers either 
from the config vtbo parm or from a default. Various vtec buffer 
headers are initialized here. 


initialize faults. pli 

initialize_faults was described eartier, under collection 
1. The entry point fault_init_two, used by callection 2, sets up 
fault vectors for normal (file system) operations. It prevents 


timer run-out faults during operation through a call to pmutSldt. 
initialize. _faults_data is used to set the main faults. Faults. 
set are: command, trouble, segment and linkage to 
fimSprimary_fault_lentry (scu data to pds$fim_data), store, mme, 
ftl, lockup, ipr, overflow, divide, df3, mme2, mme3, mme4 and Ffts 
to fimSsignal_entry (scu data to pds$signal_data), and fault 
numbers 26 to 30 to wired _fimSunexp_ fault (scu data to 
prds&sys_ trouble_data). Access violations are routed specially 
to fimBaccess_violation_entry which maps the acv fault into our 
sub-faults. Timer runeouts are sent to wired_fimStimer_runout 
(who normally calls pxss} with the scu data stored in 
prdsSfim_data. Parity goes to fim$parity_entry. Finally, we set 
up the static handlers for the no_write_permission, isct_fault 
and lot_fault conditions. 


kst util, ol 
Kst_util performs utility functions with regard to 
maintaining the kKst. The garbage collect entrypoint cleans up 


the kst ky terminating any segment not known in any ring or a 
directory with no active inferiors, : 


Start cpou.pl] 

start_cpu might best be described as a reconfiguration 
program, It is used during initialization to start a idle 
process on each configured cpu Cat the appropriate time). When 


starting the bootload cpu in collection 2, it fills in the apte 
entry for the idle process for the cpu in question. Some more 
variables in init processor are set (controller_data). A simple 
call out to init _processor$start_bootload_cpu can be made. 


syserr log init 


The syserr logging mechanism is made operative by 
syserr_tog_init. It creates the segment syserr_log which it maps 
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onto the log partition, wherever it is. A consistency check is 
made of the partition: if the check fails, the partition is 
re-inited, The syserr hproc (SyserrLoagger.Daemon.z)'s ring 0 
stack (syserr_daemon_stack) is initialized, The hproc is created 
by create_hproctearly_hproc with a stack of syserr_daemon_stack, 
dseg of syserr_daemon_dseg, pds of syserr_daemon_pds, and proce- 
dure of syserr_logger. A fast channel is defined for communica- 
tion through syserr_data to the hproc. Logging is now enabled. 


te init.ol1 


tc_init was described earlier to set up and initialize 
tc_data. tc_init$part_2, in collection 2; starts Up 
multiprogramming by creating the idle processes. This entry can 
only ke called once the initialzer's dseg is completely filled in 
by all those who read or create hardcore segments. Var ious 
variables in template_pds are filled in which are applicable to 


the idle processes. For each configured processor, a copy of 
temptate_pds and the initializer's dseg is made into appropriate 
entries in idle.dsegs and idle_pdses. The stack_O for these 


processes is made to be the prds for the given processor. The 
‘initial process for the bootload processor (the initializer 
himself} is created by threading in an apte specifying 
init _processor as an initial procedure, It is placed in work 
class zero. tom is initialized to indicate only this one process 
running. Various polling times are set for when polling becomes 
enabled as we start multiprogramming. init_processorS$init sets 
up the rest of the state, We can now call start_cpu to start the 
bootload cpu idle process. 
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SECTION 7 


COLLECTION 3 


The main task of collection three is to read itself into 
the hierarchy. Collection three consists of those programs that 
are necessary to reach ring one in the initializer's process and 
to be able to perform a reload function (Cand other maintenance 
functions). A few extraneous functions are also performed in 
collection three. 


ORDER SF EXECUTION 


Collection three starts with its main function: 
load_system is called to read the remaining mst entities into the 
hierarchy. At this time, the mst reading function is shut down. 


io_config_init initializes the data in io_config_data for 
use in later econfiguration activities. ioi_init is called to 
prepare for outer ring usage of physical devices. 


tc_initSstart_other_cpus starts up the other processors. 
Wwe now consider collection three dione and set 
sys_infoSinitialization_state to 4. 


real_initializer finally finishes, returning to 
initializer. initializer can then delete init segs through 
delete_segsSinit, real_initializer being part of one. 


Initialization then finishes by a call to init_proc, to call out 
to ring ene command level. 


MODULE DESCRIPTIONS 


fait 4 u 


init_proc is the first program run in ring zero in a normal 
process. It calls out to the initial procedure for a process in 
the outer ring. For the Initializer, the initial_proc is made to 
be system_startup_. The setting of the werking dir is skipped, 
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since we can't be sure it's there yet. The ring one stack is 
created explicitly, by makestack. system_startup_ is initiated. 
call_outer_ring. is called to "return" out to ring one Coutward 
calls are not allowed) to transfer to system_startup_. 


io_config_data is initialized by io_config_init. (It was 
allocated memory and its base pointers set up by get_io_segs. ) 
The tables are initialized in the order: iom and mpc, channel 


and then devices (as it indeed must be). 


Filling in the iom and controller entries is easy; they are 
one for one with iom and mpc cards. 


A walk is made of prph cards twice. The first pass is made 
to fill in the channel entries. Each prph card is found. If the 
peripheral is a disk or tape (has an mpc), we also find a chnl 
card Cif present). Each channel is added to the channel list. 
The internal routine controller_idx_from_chanid looks up the 
index into the controller array for the controller owning this 
channel (via ioi_configSfind_controller_card). The internal rou- 
tine iom_idx_from_chanid finds the corresponding iom array entry. 
After all of this, each channel is linked to its base physical 
channel via calls to ioi_configSfind_base_channel. 


A second pass over prph cards is made to fill in the device 
entries. For each device, we start by finding its physical 
channels. (This is done by walking down all the channels (from 
the prph and chnl cards), looking up the base channel (from the 
channel entries} and making an array of the physical channels 


found (template_pchan_array). If any of these channels is 
configured (it was marked configured above because its iom was 
on), the device becomes configured on. The device entry is 


filled in from the card. For disks and tapes, though, we add a 
device entry for the controller and one each for each drive. 


at: inte nit 

ioi_init sets up the various ici_ data bases. It walks the 
config deck, allocating group table entries for each channel 
group. Each device whose channel is accessed through a control- 
ler has its group entry flagged as a psia. The device table 


entries and channel table entries are allocated from information 
on the prph card. Then, for each chnl card, the group table 
entry corresponding is found and the channel table entries 


allocated from the information on the chnl- card. The base 
logical channel for each group is found, The group entries are 
then traversed to find storage system disk channels, All 


non-storage system disk channels are assigned to ioi_ through 
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io_manager. As a final gesture, the ioi_ page tables are setup 
(ioi_page_tablesinit). 


ioi page table. pil 


The init entrypoint of ioci_page_table is called during 
initialization to set up the io_page_tables segment. It starts 
by abs wiring the segment as one page (initially) and zeroing it. 
The header is initialized. Sixty-four word page tables are 
allocated and initialized within this page, as many as will fit. 


load system. p11 

Collection three is. loaded into the hierarchy by 
load_system. It reads the mst source (disk_reader) looking for 
segments. For each, init _branchesSbranch is called to create the 
branch (Cinit_ branches is described under collection two). The 
appropriate acl is set up, given the mst information. The 
segment contents are copied into the created branch. If the 


Initializer does not have write access to the final segment, the 
acl is cleared of this acl entry. 


te init. pl) 


tco_init was described earlier. The entrypoint 
start_other_cpus, starts cpus other than the bootioad cpu at the 
end of collection three Cafter their interference won't matter). 
A prds for the various non-bootload processors is created and 
entry-held, The pds and dsegq for the other cpu's idle processes 
was already created so we can now call start_cpu on this new cpu 
as we would normally during reconfiguration. 
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SECTION & 


MECHANISMS 


This chapter describes certain tricky and not so tricky 
mechanisms used within initialization to get things done. Also 
included is a look at the mechanism by which the various parts of 
the supervisor come into operation. 


HARDCORE SEGMENT CREATION 


There are various ways that segments come into being within 
the hardcore. These mechanisms are usually quite distinct from 
the normal method of creating a segment within the hierarchy 
Cappend$foo). 


The first group of segments that are created are those 
needed by collection zero. Collection zero itself is read in in 
absolute mode; no segments exist other than those hardware 
supplied. To save collection zero the problem of generating 
segments for its use in absoiute mode, its segments are generated 
by macros within template_slt_.alm. These macros generate not 
only the silt entries for coliection zero segments (Cand various 
segments at fixed absolute memory addresses); they also generate 
the page tables and the segment descriptor words for the 
segments. A much simpler program in absolute mode moves these 
page tables and sdws (the dsegq) to appropriate places and loads 
the dbr Calso generated by template_slt_). Thus, these carly 
segments come quickly and magically into being. All of the 
segments described by the template_slt_ are data segments with no 
initial content except for bound_bootload_O itself, which was 
loaded into the correct memory address by the bootload tape 
label, and toehold, by virtue of being the first part of 
bound_boot load_O. 


The second group of segments to come into being are the 
collection one segments loaded by collection zero. These seg- 
ments are created through a mechanism imbeded in bootload_ loader 


and bootload_dseg. When the segment header (Cactually a sit 
entry) is read from the MST, the need for a segment of a certain 
size is called for. Values in the slit header keep track of the 
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extent of memory allocated, The type of segment (permanent 
"unpaged" or not) determines from what end of memory the space 


will be obtained. A page table eof appropriate size is 
constructed in the proper area (either the segment 
unpaged_page_tables for permanent "unpaged" segments or 
int_unpaged_page_tables for temporary or to be made paged seg- 
ments). A new sdw pointing to this page table is tacked onto the 
appropriate end of dseg (low segment numbers for permanent 
segments, high for temporary or init segs). With write access 


set on in this sdw, the segment contents can be loaded from tape 
into the memory area, Proper access is then set in the sdw. The 
segment is now existent. 


Collection one creates certain data segments that are wired 


and contiguous, The most obvious is the sst. These are created 
by the routine get _main. get_main might be considered the 
counterpart of the collection zero segment creation mechanism 
when called in collection one. It also allocates memory space 


from values in the slt header. A page table of appropriate 
length in one of the two unpaged page table segments is 
constructed and a sdw fabricated to this page table. The caller 
of get_main forces this sdw into dseg and performs the appropri- 
ate associative memory clearing function. 


The other type of segment created by collection one is a 
paged segment. There are two cases of this. The first is a 
paged segment that is to be mapped against a previously defined 
area of disk. This is done when we want to access a partition or 
part thereof, as when we want toa read the config deck from disk. 
To do this, make_sdw is called, specifying that we want an sdw 
for an abs-seg. make sdw finds us an aste of appropriate size 
and threads it inte the hardcore lists, but senses the abs-seg 
switch and does not allocate pages or whatever. The cailer of 
make_sdw builds its own page table within the aste obtained by 
calling ptw_util_Smake_disk to make each page table word point to 
the correct disk . record. The pvtx of the desired disk is 
inserted into the aste. Thus, references to this segment (whose 
sdw points to the page tabie in this aste) will wake up page 
control who will page in the proper pages. This mechanism 
appears in several places; the desired way of generating such a 
segment is to call map_onto_disk. 


The second type of paged segment created by collection one 
(or two for that matter) is a segment paged off the hardcore 
partition. In this case, allocation of pages is done by page 
control. make_sdw is called as before, but, this time, it not 
only creates an aste for the segment, but it finds space for it. 
A disk with a hardcore partition with enough free space to hold 
the segment is selected. This pvtx is put into the aste. As an 
added bonus, since such segments will not have trailer entries, 
the trailer pointer in the aste is set to the hardcore segment 
number (for those programs that need to map the hardcore aste 
list entries to slt entries). The page table words are set to 4 
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nulled state. make sdw then touches each page, causing page 
control, when the page fault occurs, to withdraw a page from the 
partition. (init _hec_part created a vol map and record stock that 
page control can use which describes only the hardcore parti- 
tion.) With the segment now in existence, the caller of make_sdw 
can now load the segment. For collection one or two, this 
involves either initializing the data segment or copying in the 
segment contents read from the mst. 


When collection two needs a wired contiguous data space, it 


calls get_main also. In this case, though, get_main calls 
make_sdwSunthreaded which will obtain an aste and sdw and page 
space. pc_absSwire_abs_ contig is then called to wire this 


segment into contiguous memory pages. A paged segment to be 
mapped onto a particular area of disk is created as described for 
collection one. 


Hardcore segments that need to be placed into the hierarchy 
{deciduous segments) are so placed as follows. append is called 
to create a branch. This creates a vtoce for the segment and 
makes active, creating if necessary, all parent directories. 
Normally, segment control activities would then create an aste 
for this being created segment which would be threaded as a son 
of the parent directory’s aste., In this initialization case, 
though, the aste for the new segment already exists. We hand 
thread this aste inte the nermal segment lists and thread it as a 
son of the parent directory's aste. The directory entry for this 
segment created by append gives the vtoc index of the vtoce for 
it. By placing this vtocx into the old aste for the new segment, 
vtoc_man can make the vtoce for this now deciduous segment 
reflect the placement of this segment in the hardcore partition 
(where it was allocated during hardcore initialization). The 
segment is now properly active and accessible from the hierarchy. 


The initialization of the hardware and configuration infor- 
mation pertaining to it (basically secs (and also iom_data)) is a 
little understood process. Teo better understand the method of 
initialization, it is necessary to start with an understanding of 
the operation of the hardware on which Multics runs, This 
description pertains to the DPS-8 hardware series. The descrip- 
tion for the Level-68 series is similar but is not included. 


Interconnection of Multics hardware 
A Multics system consists of a set of system control units 


(SCU's), central processing units (CPU's) and = $ input/output 
multiplexors (CIOM's)., 
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A SCU controls access to memory. Each SCU owns a certain 
range of (absolute) memory. Any active unit €a CPU or an IGM) 
that requires access to memory does so by requesting the access 
from the SCU that owns the given range of memory. 


A CPU performs the actual computations within the system. 
It operates by requesting instructions and data from the appro- 
priate SCUs, operating upon them, and placing the results into 
appropriate locations in SCUs. 


An IOM performs input and output to physical devices, It 
requests data from SCUs to send to devices and takes data from 
devices, storing it inte Scus. 


IGMs and CPUs are not directly connected to one another. 
The .only _methed of . communication. between active modutes is 
through a SCU. The connection of modules in a Multics system is 
therefore something like the following. 


| IOM At | ISOM BI 
1 \/ | 
| /*% I 
| MEM A l---!} SCU Al | SCU B 1l---1] MEM B 1 
I Nf I 
| 4“ 1 
| cPU Al ! CPU B I 


The crosses indicate that both IGMs and both CPUs connect 
to poth SCUs: the CPUs and IGMs are not themselves connected. 


The active modules (CPUs and IGMs) have up to four ports 
that go to ScCus. These are referred to as the memory ports of 
the active module in question. The SCUs have up to eight ports 
that can go to active modules. These are referred to as the 
active module ports of the SCU or just simpoely as SCU ports, 


All CPUs and I6Ms must share the same layout of port 
assignments to SCUs. Thus, if memory port B of CPU C goes to SCU 
D, the memory port B of all other CPUs and IGMs must go to SCuU D. 
All CPUs and IGMs must describe this SCU the same; all must agree 
in memory sizes, Also, all SCUS must agree on port assignments 
of CPUs and IGMs. Thus, if port 3 of SCU C goes to CPU A, then 
port 3 of all other SCUs must also go to CPU A. 
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The various hardware modules need varying amounts of 
configuration description information with which to run. 


CPU AND [6M HARDWARE CONFIGURATION 


The CPUs and IGMs require access to main memory. They 
resolve their own internal concept of memory address (virtual or 
io page table) into an absolute main memory address. This 
address must describe a location in one and only one memory store 
wnit, which itself must be connected toe oniy one SCu, The 16M or 
CPU must determine which SCU owns the memory location desired, 
and supply that SCU with the address relative to its base of the 
location desired. _The CPU and I6M do this with the memory 
configuration information known to them by configuration switches 
and changed under software control. 


The configuration data known to the processor (Cat the 
hardware level) is found via the rsw instruction with operands of 
] and 2, which can be obtained by calling pmut$rsw with these 
operands. The format of the data returned is described in 
rsw. incl. pll and also shown below. 


The data returned by the rsw 2 instruction is shown below. 
bits meaning 


0-3 4-word/2-word interlace (Cif enabled) 
4-5 processor type (01 for DPS-8) 
6-12 seven msb's of the fault base 

13-13 id prom installed 

193-19 dps (marketing) option 

20-20 8k cache option 

23-23 Multics model CPU 

24-24 Muitics mode enabled 

29-32 cpu speed (0 = 8/70, 4 = 8/52) 

33-35 cpu number 


The data returned by rsw 1 consists of four nine bit bytes 
describing each of the four possible memory (SCU} ports of the 
processor, The bytes appear in order in the result, SCU 0 in the 
high order bits. The format of the byte is: 


bits meaning 


0-2 port assignment 

3-3 port is enabled 

4-4 system initialize is enabled 

5-5 port is interlaced with neighbor 
6-8 memory size 


8-5 AN70-01 


The actual memory size of the memory attached to the SCU attached 
to the processor port in question is 32K * 2 *x (Cencoded memory 
size). The port assignment couples with the memory size to 
determine the base address of the SCU connected to the specified 
CPU port (absolute address of the first location in the memory 
attached to that SCU). The base address of the SCU is the 
(actual memory size) * (port assignment). 


The 16M has similar port description information 
interpreted similarly. This information is not readable from the 
CPU, 


SCU HARDWARE CONFIGURATION 


The SCuU also has description of its perts (to CPUs and 
IOGMs) as well as description of the store units attached to it. 
This information is determined by the rser instruction 
(pmut$rscr), given the SC_CFG argument. (The explanation of the 
rscor instruction appears later.) The portions of the result that 
pertain to SCU port and store unit configuration are shown below. 


bits meaning 


09-17 lower store size 
12-15 store unit (A Al B Bi) on-line 
21-21 SCU in program mode (vs manual) 


22-22 non-existant address checking enabled 
23-293 non-existant address limit 

30-30 store unit interlace enabled 

31-31 B is lower addressed store (vs A) 
32-35 port enable mask for ports 0-3 

57-63 cyclic priority (0/1-6/7) 

68-71 port enable mask for ports 4-7 


A DPS-8 SCU may have up te four store units attached to it. 
If this is the case, two store units form a pair of units. The 
size of a pair of units (or a single unit) is 32K * 2 x* (lower 
store size) above. 


If the non-existant address flag is on, any address to a 
Store unit whose high order bits (above the lower 15) is greater 
than or equal to the non-existant address limit generates a 
non-existant address SCU illegal action. 

A SCU will respond to and provide information to only those 
ports that are enabled (port enable mask above). 
SCU ADDRESSING 

There are three ways in which an SCU is addressed, In the 


normal mode of operation (memory reading and writing), an active 
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unit CIGM or CPU) translates an absolute address into a memory 
port (fon it) anda relative memory address within the memory 
described by the memory port. The active module sends the 
address to the SCU on the proper memory port. If the active 
module is enabled by the port enable mask in the referenced Scu, 
the SCU will take the address given to it and provide the 
necessary memory access. 


The other two ways pertain to reading/setting control 
registers in the ScCuU itself. For each of these, it is still 
necessary to specify somehow the memory port on the CPU whose SCU 
registers are desired. For the rmcm, smcem and smic instructions, 
this consists of providing a virtual address to the processor for 
which bits 1 and 2 are the memory port desired. 


The rsecr and sscr instructions, . though, key off the final 
absolute address to determine the SCU (or SCU store unit) 
desired. Thus, software needs a way to translate a memory port 
number into an absolute address to reach the Stu. This is done 
with the paged segment scas, generated by init_scas (Cand 
init _scu). scas has a page corresponding to each SCU and to each 
store unit in each Scu., pmutsrscr and pmutSsscr use the memory 
port number desired to generate a virtual address into scas whose 
absolute address (courtesy of the ptws for scas) just happens to 
describe memory within that SCU. 


The cioec instruction (discussed below) also depends on the 
final absolute address of the target operand to identify the Scu 
to perform the operation. In the case of the cioc instruction, 
though, this has no particular impact in Multics software. All 
target operands for the cioc instruction when referencing I6Ms 
are in the low order SCU. When referencing CPUs, the Scu 
performing the connecting has no real bearing. 


As mentioned earlier, communication between active modules 


(CPUS and IGMs) can only be performed through SCcUs. 


CPUS communicate to IGMs and other CPUs via the cioc 
connect ifo channel) instruction. The operand of the instruction 
is a word in memory. The SCU containing this operand is the SCU 
that performs the connect function. The word fetched from memory 
contains in its low order bits the identity of a port on the SCU 
to which this connect is to be sent. This only succeeds if the 
target port is enabled (port enable mask) on the SCU. When the 
target of the connect is an I6M, this generates a connect strobe 
to the I6M., The I6M examines its mailbox in memory to determine 
its course of action. When the target of the connect is another 
CPU, this generates a connect fault in the target processor. The 
target processor determines what course to follow on the basis of 
information in memory analyzed by software. When a connect is 
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sent to a processor (including the processor issuing the con- 
nect), the connect is deferred until the processor stops 
executing inhibited code Cinstructions with the inhibit bit set). 


Signals sent from an IGM to a CPU are much more involved. 
The basic flow is as follews. The 108M determines an interrupt 
number. (The interrupt number is a five bit value, from 0 to 31. 
The high order two bits are the interrupt level. 


Oo - system fault 


1 - terminate 
2 7- marker 
3 - special 


The low order three bits determines the ISM and I6M channel 
group, ) ane? . 


O - I6M O channels 32-63 
1 - I6M 1 channels 32-63 
2- I6M 2 channels 32-63 
3 - IGM 3 channels 32-63 
4 - 18M 0 channels 0-31 
5 - 16M 1 channels 0-31 
6 - ISM 2 channels 0-31 
7 - IGM 3 channels 0-31 


It also takes the channel number in the group (0-31 meaning 
either channels 0-31 or 32-63) and sets the <channel number>th 
bit in the <interrupt number?>th memory location in the interrupt 
mask word CIMW) array in memory, It then generates a word with 
the <interrupt number>th bit set and sends this to the bootload 
SCU with the SXC (set execute cells} SCU command. This sets the 
execute interrupt cell register in the SCU and sends an XIP 
(execute interrupt present) signal to various processors 
connected to the SCU, (The details of this are covered in the 
next section.) Gne of the. processors (the first to get to it) 
sends an XEC (execute interrupt cells} SCU command to the SCU who 
generated the XIP signal. The SCU provides the interrupt number 
to the processor, who uses it to determine the address of a fault 
pair in memory for the "fault" caused by this interrupt. The 
processing of the XEC command acts upon the highest priority 
(lowest numbered) bit in the execute interrupt cell register, and 
aiso resets this bit in the register. 


interrupt Masks and Assignment 


The mechanism for determining which processors are candi- 
dates for receiving an interrupt from an I0M is an involved 
topic, First of all, a processor will not be interrupted as long 
as it is executing inhibited instructions Cinstructions with the 
inhibit bit set). Beyond this, though, lies the question of 
interrupt masks and mask assignment. 
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Internal to the SCU are two sets of registers (A and 8B), 
each set consisting of the execute interrupt mask register and 


the interrupt mask assignment register. Each execute interrupt 
mask register is 32 bits long, with each bit enabling the 
corresponding bit in the execute interrupt cell register. Each 


interrupt mask assignment register has two parts, an assigned bit 
and a set of ports to which it is assigned (8 bits). When a bit 
is set in the execute interrupt cells register, the SCU ands this 
bit with the corresponding bit in each of the execute interrupt 
mask registers. If the corresponding bit of execute interrupt 
mask register A, for example, is on, the SCU then looks at the A 
interrupt mask assignment register. If this register is not 
assigned (enabled), ne further action takes place in regards to 
the A registers. (The B registers are still considered (Cin 
parallel , by the way). ) If the register is assigned (enabled), 
then interrupts. will be sent to. all ports (processors) whose 
corresponding bit is set in the interrupt mask assignment 
register. Thus, enly certain interrupts are allowed to be 
signalled at any given time (based on the contents of the execute 
interrupt mask registers) and only certain processors wilt 
receive these interrupts (as controlled by the interrupt mask 
assignment registers). 


In Multics, only one processor is listed in each of the two 
interrupt mask assignment registers, and no processor appears in 
both. Thus, there is aone for one correspondence between 
interrupt masks that are assigned (interrupt mask registers whose 
assigned fenabled) bit is on} and processors who have an 
interrupt mask (SCU port number appears iin an interrupt mask 
assignment register). So, at any one time only two processors 
are eligible to receive interrupts. Other processors need not 
worry about masking interrupts. 


The contents of the interrupt mask registers may be 
ebtained with the SCU configuration information with the rser 
instruction and set. with the sscr instruction. - 2 gE 38 


bits meaning 


00-07 ports assigned to mask A (interrupt mask assignment A) 
08-08 mask A is unassigned (disabled) 
36-43 ports assigned to mask B (interrupt mask assignment B) 
44-44 mask B is unassigned (disabled) 


The contents of a execute interrupt mask register are 
obtained with the rmcm or the rscr instruction and set with the 
smcm or the sscr instruction. The rmom and smem instruction only 
work if the processor making the request has a mask register 


assigned to it. If not, rmcm returns zero (no interrupts are 
enabled to it) anda smem is ignored Cactually, the port mask 
setting is till done), The rsecr and sscr instructions allow the 


examining/setting of the execute interrupt mask register for any 
port on a SCU; these have the same effect as smcoem and rmem if the 
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SCU port being referenced does not have a mask assigned to it. 
The format of the data returned by these instructions is as 
follows, 


bits meaning 


00-15 execute interrupt mask register 00-15 
32-35 SCU port mask O-3 
36-51 execute interrupt mask register 16-31 
68-71 SCU port mask 4-7 


Operations upen masks 


Since at most two processors have interrupt masks assigned 
to them, not all processors can manipulate their own masks. But, 
to remove the need for processors to ask whether they have a mask 
before operating upon them Cin partiuclar, to mask interrupts), a 
mechanism has been devised. It's execution is carried out by by 
pmutSset_mask and pmutSread_mask. The code fragment of pmut that 
reads/sets the mask follows. 


read_mask: 


«11 prds$processor_tag 

Tprpab sces$mask_ptr, x1 

KxeC scstread_mask, x1 
set_mask: 

1x11 prds$processor_tag 

iprpap scs$mask_ptr, x1 

xec scst set_mask, x1 


For each processor tag, then, there is a set of data pointers and 
instructions in scs$mask_ptr, scs$read_mask and scs$set_mask that 
either operate upon the processor's mask or pretend they did. 
When the processor in question does not. have an interrupt mask, 
the data is as follows: 


mask_ptr - packed pointer to 
prdstsimulated_mask 


read mask: 
1daq abio 


set_mask: 
stag ablo 


which will succeed in doing nothing. when the processor does 
have an interrupt mask, the data is as follows: 


mask_ptr - packed pointer to 
scstport_addressing_ word({bootload scu) 
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read_mask: 


rmom ablo, x 
set_mask: 
smem abio, * 
which will read and set the mask, The array 


scstport_addressing_word contains the data words required as 
eperands for the rmecm, smcem and smic instructions. They contain 
the memory port number in their low order bits Ci.e., their array 
index is their contents). The smic instruction uses 
scstinterrupt_controller (the low order memory port (address 0)) 
as ian array index to perform the smic against the lew order SCU., 


The operands of the pmut$read_mask and pmutSset_mask opera- 
_tions (rmem and smem instructions, respectively). were described 
above. The value scs$sys_level masks all interrupts. It has 
zeroes for all bits loaded into the execute interrupt mask 
register but has ali ones for all ports of the SCU to which 
enabled active modules are connected. scs$open_level has the 
same SCU port enable bits but has ones for all interrupts of all 
levels from both channel sets of all ISMs currently active. 


Configuration initialization eccurs orimarily within 
scs_and_clock_init, iom_data_init, scas_init and init scu called 
from within scas_init. 


The name of this routine should probably be just scs_init. 
The clock portion is really just a check of clock functioning 
{and setting up clock data in general}. It fills in the 
scstport_addressing_word's as descr ibed above. 
sestprocessor_switch_data is read to get the configuration and 
data switch values.  scs$bos_processor_tag is set... to indicate 
this cpu (currently the only one running) as the bootload cpu, 
scs$read_mask, scs$set_mask and scs$mask_ptr are set to the dummy 
values mentioned above. When scs_and_clock_init is run, ail 
interrupts are masked, and no one really needs to think about its 
masks. The various processor ports are examined looking for 
memories. The port number of the tow order memory so far is set 
into ses$ interrupt_controller and sys_infoSclock_. When 
scs_and_clock_init is finsihed, then, the configuration data for 
the bootload cpu is known, as well as for the various memories 
attached to it. Examination of this data and setting of masks 
waits for later programs. 


iom_data_init initializes the data needed by io_manager. 
This includes descriptions of the various IGMs and their chan- 
nels. The kasic setup of this information (numbers) of IGMs, 
numbers of channels) was set up by get_ioc_segs who obtained this 
data from the config_deck. Most description of IOMs appears in 
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iom_data soa no major changes take place to scs within 
iom_data_init. 


Aside from filling in scw's and lpw's for each 
channel_table and mailbox entry, the more interesting part of 
iom_data_init is the main ISM card processing loop. It examines 
each IGM card, making sure that no 16M is duplicated, that the 
field values are reasonable, that no card claims an SCU port 
claimed by another IGM Cand sets scs$port_data to claim the I6M) 
etc. The iom_data.per_iom data is initialized as to configured, 
on_ line, paged, etc. This routine adds to scsS$open_level the 
necessary bits to enable interrupts from the IGMs, (Interrupts 
are not enabled until initialize faulstS$interrupt_init.) 


The conclusion of configuration initialization occurs in 
scas_init and its servant, init_wscu. At its entry, .scsSport_data 
has been set up to only describe the IOMs. This routine will set 
these for processors. It also initializes scas, as its name 
implies. This requires determining all memories and store units. 
Aside from this, the routine checks the port enable switches for 
the processor ports for correctness. 


The first loop of interest scans all CPU cards. It checks 
them for reasonableness, that no CPU is mentioned twice, that no 
ether active module claims this SCU port, etc. The cow's 


{connect operand words) used when perfoming cioc's to this 
processor are set. 


What follows this is the SCU scanning loop. It takes each 
MEM card and checks it for reasonableness, whether tags are 
duplicated, whether the memory extent (from rsw_util) matches and 
does not overlap any other memory, etc. init_scu is then called. 


init_scu initializes an S$CU. This is the routine that sets 
up scas for a particular SCU. This is done by installing ptw's 
into the page table for scas to describe the ScCu. Reading the 
configuration from the SCU, the data is compared against the 
computed data given the processor configuration information 
(which scas_init compared against the config_deck description of 
the memory). If the configuration from the SCU indicates 
aditional store units, the scas pages for them are set (to allow 
getting the store unit mode registers with an rser). 


The mask checking part of init iscu makes sure that each 
interrupt mask that is assigned on the SCU is assigned toa 
processor (as opposed to an 16M) and that no more than one mask 
indicates a given processor. This is done by walking down the 
CPU data in ses and comparing the mask data recorded for the 
other processor ports for duplication. This also records which 
masks assigned for this SCU are claimed by processors. Any mask 
that is assigned that does not appear in the description of a 
processor is mis-assigned. 
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After the SCUs have been initialized in this way, a little 
‘more work is left. The bootload CPU's ports are checked, so that 
no extra port is enabled. For each IGM Cand the bootload CPU), 
the port enable bit is set in each SCU. 


For each processor, we find the processors with masks 
assigned. For these, we set scs$set_mask, scs$read_mask and 
scs$mask_ptr to actually perform the rmcm and smem instructions 
as described above to manipulate their masks. We check to be 
sure that the bootload CPU owns one of the masks. 


The final loop examines the ordering of active modules on 
the SCUs to see if the cyclic priority switches can be set. This 
is only done if the IOM group does not overlap the CPU group. 


PAGE CONTROL INITIALIZATION © 


Page control initialization consists of a variety of 
activities run during collection one. init_sst build the sst and 
core_map. The sst is needed since we need to have an aste for 
page control so that it can find what disk needs i/o (from the 
pvtx within the aste}. The core_map is needed since it shows the 
status of memory pages (initially free between the groups of 
initialization segments, currently wired). Page control needs 
this information so it can find a free memory frame into which it 
can read a desired page. init_pvt performs the function of 
creating the pvt. It is the index inte the pvt for the device 
from which a page (or other i/o) is desired that is needed by 
disk_control (detl). read_disk$init is needed to initialize page 
reading/writing through rdisk_seg. This routine builds the paged 
segment rdisk_seg, which can be mapped onto the desired page of 
disk to read. The aste for rdisk_seg contains the pvtx of the, 
disk to read. The page table word for rdisk_seg provides the 
disk address. At this point, we can actually read or write a 
page by touching rdisk_seg within read_disk. read _ disk sets up 
the aste and page table word, as described. When the page is 
touched, a page fault will wake up page control. It will find a 
free memory frame, read the page in, and resolve the page fault. 


read_disk_label uses read_disk, then, to read a disk label. 
init _root_vols uses read_disk_label to read the label of hardcore 
partition volumes. Given the label, it finds the partition map 
and finds the hardcore partition. A small volmap is built that 
describes this partition and is mapped onto the beginning of the 
partition. A small record stock is built to describe the volmap. 
Given this initial stock, attempts to create or free pages on a 
disk (within the hardcore partition) can succeed. Now, we can 
create hardcore segments by building null page tables and taking 
page faults. Page control will find a free page from the volmap 
for the partition (whose pvtx is in the aste) and resolve our 
page fault. At this point, all of the services we need of page 
control are available. For the ease of later activities who need 
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various partitions to map paged areas onto, init_partitions is 
called to validate the part information. We now page happily. 


Later, im collection two, the real volmaps 9 and record 
stocks are set up by acceptirpyv. After this point, page control 
will simply shift its page creation/freeing activity to that 
described by the paging region. All hardcore segments had their 
pages pre-withdrawn from the hardcore partition, so no possibili- 
ty exists that we will accidentally put a paging region page into 
a hardcore segment. 


SEGMENT AND DIRECTORY CONTROL INITIALIZATION 


Segment and directory control are initialized in stages 
throughout collections one and two. It started in collection one 
when the sst was built. It continues into collection twe with 
getuidBinit. This allows us to generate unique ids for newly 
created segments and directories. init_vtoc_man paves the way 
for vtoc_man to perform i/o on vtoces. Segment control's trailer 
segment is created by init_str_seg. accept_rpvy sets up the real 
vtoc maps and vtoc stocks. Now vtoc_man can really read and 
write vtoces, as well as create and free them. Now, if we were 
to try a normal activation of a segment, given its pvtx/vtocx, we 
could find the segment and thread the segment into the right 
astes and trailers. init_lvt builds an initial riv Cin the lvt) 
out of the disks listed as having hardcore partitions. This 
allows segment control's disk selection algorithm to be able to 
find a disk to use when segments try to be created. We now have 
enough mechanism in place to utilize most of the facilities of 
segment control, but we cannot yet access and activate hierarchy 
segments. 


The initialization of directory control is imbedded within 


the initialization of segment control. It started with 
dir_lock_init providing us with an initially empty list of. locked 
directories. The real start up of directory control, though, 


eccurs in init root dir. This builds the kst (used at segment 
fault time to resolve segment numbers into an understanding of 
what needs activation) and creates Cif need be) and activates and 
initiates by hand the root directory. Directory control can now 
reference hierarchy objects with segment control's help. Any 
attempt to create a hierarchy segment (append) can succeed by 
selecting a disk (lvt lookup), vtoce creation (vtoc_man using 
¥Vtoc stock, vtoc map and vtoc buffers) and aste creation Cusing 
sst and the trailer seg). Also, deactivation is possible since 
the trailer is built to describe what to setfault and the kst is 
present to be able to re-activate. At this point, we are able to 
handle segment faults, given the information in the kst and by 
recursively traveling down the hierarchy by virtue of the fact 
that the root is now and always active. 
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SEGMENT NUMBER ASSIGNMENT 


There are basically three classes of segments as far as 
segment number assignment is concerned. The first is segments 
that will be a permanent part of the supervisor. These are 
assigned consecutive segment numbers, starting at O. dseg is 
always 0, of course. 


The second class is initialization and collection temporary 
segments. These are assigned consecutive numbers starting at 400 
octal. Although temporary segments are deleted at the end of 
each collection, their numbers are not re-used. We continue to 
assign the next non-used number to the next temporary or 
initialization segment. 


The order of assignment of these numbers is purely 
according to the order that the segments are encountered. The 
first few segments are assigned numbers by template_slt_; but, 
again, this is in order of encounterance. The only requirements 
are that dsegq must be segment 0 and that the slt must be segment 
7 Cassumed by all dump analyzers). 


Normal hierarchy segments fall into the third class of 
segments, as far as segment number assignment is concerned. As 
for these, the sequence is as follows. The next higher mod 8 
segment number after the last permanent supervisor segment is 
chosen as the stack base (ring zero stack number). The next 
seven numbers are assigned to the outer ring stacks, in order. 
Since the root is made active after this, and the root becomes 
the first real hierarchy segment initiated, it gets the segment 
number after stack_7. Sther segments are assigned progressively 
higher segment numbers according to segment control's normal 
rules, We do not need to worry about running into segment number 
400 octal since these segments will be deleted before we ever get 
that far. Sniy permanent supervisor segments will show up in 
one's dseg. 


Some supervisor segments (deciduous segments) get initiated 
into the normal user's address space. Regular stacks are 
initiated by special handling (makestack called from the segfault 
handler) and are directly referred to by the reserved stack 


segment numbers. A normal segment like bound_library_1l_ is 
activated through normal segment control means. Thus, it will 
appear in two places in the user's address space; one in the 


supervisor segment number range (with ring brackets of 06, O, O, 
by the way) and once in the user ring segment number range 
(greater than the root's segment number) (with ring brackets of 
Oo, nn, mn}, , 


This is a problem for hardcore gates, though, relative to 
their linkages. A user ring call to bound_library_1_ will cause 
modules within it to find their linkage section from the lot 
entry for this seament. Any module called from bound_lLibrary_1_ 
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will also be in the user ring, so the user ring linkage section 
for the segment number corresponding to the user ring version of 
bound_library_1_ will find the called module. Hardcore gates, 
however, don't call hierarchy entities but instead call entities 
that can only be found through the linkage section generated via 
pre-linking during initialization which resides in the ring zero 
linkage section corresponding to the hardcore segment number. To 
make it possible to find this easily, init _hardcore_gates stored 
into the hardcore gate segdef .my_lp the pointer to this linkage 
section. Thus, when called from the cuter ring with the outer 
ring segment number, hardcore gates will quickly switch over to 
the hardccre linkage section and function property. 


IRAFFIC CONTROL, INITIALIZATION 


All three collections contribute efforts toward enabling 
traffic control, Collection one starts by building the te_data . 
segment in tc_init, full of empty aptes to describe processes. 
At this time, though, a flag in tc_data indicates that 
mult-programming iS Mot active, Any call to traffic control to 
pxss$wait will simply loop for notification (which will come from 
a call to pxss$notify in some interrupt routine). No polling 
routines are run at this time. Sther initialization activities 
proceed to build the supervisor address space. 


Collection two starts up multi-programming. It dees this 
through te_init$part_2. Multi-programming requires 
multi-processes;: initially this is the Initializer and an idie 
process, but it s00n encompasses answering service created 
processes and hardcore processes (hprocs)., Creating an idle 
process requires creating a pds, stack_O (prds) and dseg for it. 
The dseg and pds are simply copies of those for the Initializer, 
now that they are filled in. apte entries for the Initializer 


and for idle are created. We can now consider multi-programming 
to ke on. start_cpu is called to start the processor. For. the 
bootload processor, this means calling init _processor in a 
special case environment (non-absolute mode, if nothing else). 
init_processor (the idle loop) marks itself as a #running 
precessor, sends itself a connect, and unmasks the processor. 


The connect will go to traffic control, who will pre-empt idle 
and return control to Initializer. 


In collection three, start_cpu is called (from 
tc_init$start_other_cpus) in the same manner as would be dene for 
adding a cpu during reconfiguration, This is semewhat described 
in the reconfiguration manual. 
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SECTION 9 


SHUTDOWN AND EMERGENCY SHUTDOWN 


The goal of shutdown, obviously enough, is to provide an 
orderly cessation to service. A normal shutdown is one in which 
the system shuts itself down, following the direction of the 
eperator's “shut" command. An emergency shutdown is that opera- 
tion invoked by bce which forces Multics to run 
emergency_shutdown, which performs the clean up operations below, 


Sne could consider the system to be shutdown if one simply 
forced a return to bce, but this is not enough. Proper shutdown 
involves, at first, the answering service function of logging out 
all users. The answering service then shuts itself down, 
updating final accounting figures. Now with just the [Initializer 
running, the task of shutdown described here follows. 


The major goal of shutdown and emergency_shutdown is to 
maintain consistency of the storage system. It is necessary to 
move all updated pages of segments to disk, to update all 
directories in question with new status information, to update 
vtoces of segments referenced, and to clear up any effects caused 
by the creation of supervisor segments. 


These functions must be performed in several stages. Also, 
the ordering of operations is such as to minimize the degree of 
inconsistency within the storage system that would occur if a 
failure were to occur at any point. 


Since these same functions are performed for an emergency 


shutdown, the operations are performed so as to assume as little 
as possible from the information in memory. 


ORDER GF EXECUTION SF SHUTDOWN 


The module shutdown is called via hphcs_Sshutdown. It 
starts by removing the fact that we were called from an outer 
ring, so we won't accidentally return. An any_other handler is 


set up to flag any possible error, later. The first action of 
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shutdown is to force itself to run on the bootload cou and to 
stop the others (stop_cpu). 


disk_emergency$test_all_drives checks out ali of the stor- 
age system drives at once to avoid errors later. 


tc_shutdown destroys the remnants of any processes and 
turns off multi-processing. 


scavenger$shutdown cleans up any scavenges that were in 
progress, 


We then switch over to the stack inzr_stkO for the rest of 
shutdown. This is performed through the alm routine, 
switch_shutdown_filtle_system, which starts the file system shut 
down. 


shutdown_file_system is the first program called on 
inzr_stkoO., It is adriver for the shutdown of the file system. 
It starts by updating the rpv volmap, vtoc header (and vtoc map) 
and label of the rpv to show the current state (in case problems 
occur later). 


The most important step, from the user's point of view, is 
to flush all pages in memory (considered to be part one of 


shutdown) with pecsSflush. This is relatively easy and safe to 
perform since it only requires walking down core map entries; sst 
threads, etc. do not have to be trusted. This marks the 


completion of (emergency) shutdown, part 1. 


The stack zero segments are released so that demount_pv can 
deactivate them. 


deactivate_for_demountS shutdown deactivates all 
non-hardcore segments and reverts deciduous segments (removes 
from the hierarchy those supervisor segments put into the 
hierarchy during initialization). This updates the directories 
containing those segments that were active at shutdown time Cand 
their vtoces). 


Sur next task is to remeve the pages of these updated 


directories from memory. We start by demcunting all operative 
disks (other than the rpv) with demount_pyv. After this, if any 
locks remain set, we set the shutdown state to three; it is 


normally four. 


If any disks are inoperative, we just perform another 
memory flush (to remove rpv directory pages}, wait for console 
ifo to finish Cocdem_Sdrain_io) and return to bee. 


If all was okay, we demount the rpv with demount_pv. The 


storage system is now considered to be shut down. The ssenb flag 
in the flagbox is reset to show this. We flush memery once more, 
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to get the last log messages out. The message "shutdown 
complete" is printed; we wait for console completion. Shutdown 
can now return to bce. 


ORDER GFE EXECUTION SF EMERGENCY SHUTDOWN 

emergency shutdown is called from bce. bce modified the 
machine conditions of the time of return to bce to cause a return 
to emergency. shutdown! oO, This module initializes itseif through 
text imbeded pointers to its linkage section, etc. and enters 
appending mode. 

Multi-programming is forced off (tc_dataSwait_enabie). 


«The apt, metering and various apte locks are forced 
unlocked, 


The return to bce earlier stopped all of the other cpus. 
sestprocessor is set to show this fact. 


The connect lock is forced unlocked. 


Various trouble pending, etc. flags are reset in case of 
another failure. 


scs masks, etc. are set up for single (bootload) cpu 
operation. We mask down to sys_level. 


A switch is made to the idle process. This is done by 
using scs$idle_aptep to find the idle's apte. Its dbr is leaded. 


All ether cpus are set to delete themselves, im case they 
try to start. 


The idle process has prds as its stack. A stack. frame is 
pushed onto this stack by hand. 


The ast and reconfiguration locks are forcibly unlocked, 

The first external module is called. ocdcm_S$esd_reset 
resets oc_data, and the console software. 
syserr_realSsyserr_reset resets the syserr logger and the 
syserr_data segment and flags. 

io_managerSreset resets iom_data status. 


pageSesd_reset resets its view of the disk dim. 


pc_recover_sst recomputes the page control state. 
pageStime_out is called. 
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disk_emergencyS$test_all_drives_masked runs as for normal 
shutdown, but in a masked state. 


The prds is abandoned as a stack (it is reset) and the 


Stack pointer set to null Cidle process). The first page of 
template_pds is wired and the sdw for pds set to point to 
template_pds (hopefully a good pds). The first page is touched, 
hopefully successfully paging in the page. The stack pointers 
are then set to inzr_stko. Wwe then call 


wired_shutdown$wired_emergency. 


wired_shutdown sets an any_other nandier and unmasks the 
processor. It makes a few checks to see if the storage system 
was enabled, If a vtoc_buffer is in the unsafe state, its 
physical volume has its trouble count incremented. 


For each pvte, the scavenger data is reset as in @ normal 
shutdown. pagetreset_pvte is called. Emergency shutdown part 1 
is started, 


fsout_vol updates the rpv information on disk as for 
shutdown. 


Pages of segments are flushed from information in the core 
map entries (pc$flush). The rpv information is again written. 
This ends part one of emergency shutdown. 


vtoc_man$stablilize gets vtoc buffers into shape. 


We can now call shutdown_file_system and let normal opera- 
tions carefully try to update directories and vtoces, as for a 
nermal shutdown. 


MODULE DESCRIPTIONS 


deactivate for demount.p1y 


Other than the flushing of pages themselves, the 
deactivation of segments Cupdating their directory entries and 
vtoces) performed by deactivate_for_demount is one of the most 
important functions of shutdown. The deactivations are performed 
by hand so as not to disturb aste threads. The operation 
consists of walking dewn the ast hierarchy (tree)-wise, 
recognizing that each active segment has all of its parent 
directories also active. We start at the root. For each segment 
to consider, we leek down its inferior list. Each look at an 
aste and an inferior element is performed with a variety of 
Validity checks on the aste (within pool boundaries, parent/son 
pointers correct, etc). If inferiors exists, they are pushed 
onto a stack (max hierarchy depth deep) of astes to consider. 
When we push an aste with no inferiors, we consider it directly. 
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If it was a hardcore segment (deciduous), it is removed from the 
aste list it is in and its vtoce freed. Non-hardcore segments 
have their pages flushed (pc$cleanup) if they are not entry~held 
Centry-held segments, such as pdses had their pages flushed 
earlier and will be caught in the final flush) and their vtoces 
updated (update_vtoce$deact). After a segment is considered, its 
brothers are considered. When they are done, we return back to 
their parent for consideration. We proceed in this manner until 
we consider and pop the root aste off the stack. Segment control 
is now no lenger active. 


demount pv pl 


demount_pv demounts a physical volume. It starts by 
waiting for everyone to relinquish the drive; that is, no one can 
be in the middle of a physical volume operation. All segments on 
the volume are deactivated. For the shutdown case described 
here, a special deactivation is performed to avoid possible 
problems in the case of emergency shutdown. Each aste pool is 
traversed (by numerical order, not link order because of possible 
mis-linkings). All non-hardcore segments (except the root) are 
deactivated in-line by calling pctBcleanup and update_vtoce$deact 
on the segment. We then wait for all vtoc i/o to complete to the 
disk. fsout_vol is called to update the volmap, vtoc header and 
map and the label. Finishing, we clean up the pvt entry. 


disk emersency.p11 


To ease the burden on shutdown ef drives being inoperative, 
disk_emergency$test_all_drives is called. It tests all storage 
system drives by first assuming that each one is good, then 
running disk_control$test_ drive. If the drive is declared inop- 
erative this time, it is marked as such with an error report 
printed. Shutdown of objects on this drive will be suspended, 


emergency shutdown. alm 


bce, when crashed to, received the machine conditions at 
the time of the call to bce. For an emergency shutdown (esd), 
bce patches these to force a transfer to emergency_shutdown!0O. 
Multi-programming is forced off (tc_data$Swait_enable). The apt, 
metering and various apte locks are forced unlocked. The return 
to bce earlier stopped all of the other cpus. scstprocessor is 
set to show this fact. The connect lock is forced unlocked. 
Various trouble pending, etc. flags are reset in case of another 
failure. scs masks, etc. are set up for single (bootlead) cpu 
operation. We mask down to sys_level. A switch is made to the 
idle process. All other cpus are set to delete themselves, in 
case they try to start. The idle process has prds as its stack. 
A stack frame is pushed onto this stack. The ast and 
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reconfiguration locks are forcibly unlocked. ecdcm_$esd_reset 


resets oc_data, and the console software, 
syserr_realSsyserr_reset resets the syserr logger and the 
syserr_data segment and fiags. io_managerSreset resets iom_data 
status. page$Sesd_reset resets its view of the disk dim. 
pc_recover_sst recomputes the page control state. pages time_out 
is called. disk_emergencyStest_all_drives_masked runs as for 


nermal shutdown, but in a masked state. The prds is abandoned as 
a stack (it is reset) and the stack pointer set to null Cidle 
process). The first page of template_pds is wired and the sdw 
for pds set to point to template_pds (hopefully a good pds). The 
first page is touched, nopefully successfully paging in the page. 
The stack pointers are then set to inzr_stko. We then call 
wired_shutdownSwired_ emergency. 


fsout vol,olt 

fsout_vol is called whenever a volume is demounted, This 
includes the shutdown equivalent function. It endeavors to 
update the volume map, vtec header and map and label for a 
physical volume. It drains the vtoce stock for the disk 
(vtoc_stock_man$Sdrain_stock) to return those vtoces withdrawn 
previously. The vtoc map is then forced out to disk. We can 


then free the vtoc stock. We similarly drain, write out and free 
the record stock/map. The dumper bit map is freed and updated to 
disk. The time map updated and mounted is updated in the label. 
If this is the root, this is the program that records in the 
label such useful information as the disk_table_vtocx and uid and 
the shutdown and esd state. 


s e 1 


The shutdown entrypoint to scavenger is called during 
shutdown to clean up any. scavenge operations in progress. It 
walks down scavenger_data looking for live entries. For each, it 
clears the corresponding pvte fields deposit_to_volmap, 
scav_check_address and scavenger_block_rel which affects the 
operation of page control. 


todow j 
This is the starting driver for shutdown operations. It is 
called from hphcs_Sshutdown from the Initializer command 
shutdown. It forces itself to run on the bootload cpu and it 


stmps the others. disk_emergency$test_all_drives test the drives 
before use. te_shutdown stops and destroys the other processes. 
scavenges are stopped (scavengersshutdown). We then switch 
stacks back to inzrostkO and proceed through shutdown within 
switch_shutdown_file_ system. 
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shutdewn file system. pli 


shutdown_file_system is the driver for the shutdown of the 
file system. It runs on inzrestko. Its operations include: 
fsout_vol updating of the rpv, flushing pages of segments, 
releasing stack_O segments for deactivation purposes, running 
deactivate_for_demount$shutdown to deactivate non-hardcore seg- 
ments and revert supervisor segments threaded into the hierarchy 
at initialization (updating directories as aresult) and then 
flushing memory again (by calls to demount_pv for the various 


disks). This module keeps track of the state of operativeness of 
drives; if any are incperative, we just perform a final flush and 
quit: otherwise we can demount the rpv also. A final flush is 


performed to get syserr log pages out. After console i/o has 
drained, we can return to bce. 


switch shutdown file system. alm 


switch _shutdown_file_system is the first program ina set 


to shut down the file system. It moves us back to inzr_stkO, the 
initialization stack for eur processing. While it is fiddling 
with stack pointers, it also sets pds$stack_O_ptr and 
pds$ stack_O_sdwp. on this new stack, it calls 


shutdown_ file system. 


tc shutdown. pli 


Traffic control is shutdown by tc_shutdown. It flags the 
system as being in a shutting down state 
(tc_dataSsystem_shutdown). It also sets wait_enable to 0, 
disabling multi-programming. For each process in the apt, 


deactivate_segs is called, destroying the process and finishing 
eur task, 


wired shutdown, pill 

The module wired_shutdown is the counterpart to shutdown in 
the esd case. It starts by setting an any_other handler and 
unmasking the processor. It makes a few checks to see if the 
storage system was enabled. If a vtoc_buffer is in the unsafe 
state, its physical volume has its trouble count incremented. 
For each pvte, the scavenger data is reset as in a normal 
shutdown. pageSreset_pvte is called. Emergency shutdown part 1 


is started. fsout_vol updates the rpv information on disk as for 
shutdown. Pages of segments are flushed from information in the 
core map entries (pcSflush). The rpv information is again 
written, This ends part one of emergency shutdown. 
vtoc_manSstablilize gets vtoc buffers into shape. We can now 
call shutdown_file_system and let normal operations carefully try 
to update directories and vtoces, as for a normal shutdown. 
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APPENDIX A 


GLOSSARY 


abs- seg 


bce 


An abs-seg is a reserved segment number in the hardcore 
address space used to access disk or memory outside of the 
normal mechanisms. That is, they are not built by the 
normal functions that append to the storage system nor are 
they built by the functions that create segments out of the 
hardcore partition or initialization memory. Examples of 
abs-segs are segments mapped onte an area of disk to allow 
paging to he used to read/write them (such a mechanism is 
used to read the config deck from disk) or segments mapped 
onto an area of memory for examination (page control does 
this to examine pages being evicted). abs-segs are managed 
(i.@., created and deleted), each in its own way, by a set 
ef software created for the purpose; Gne may not use the 
standard system functions to operate upon them (such as 
segment deletion). However, the contents of the segments 
are addressed through normal mechanisms; that is, memory 
mapped abs-segs are referencable via the hardware and 
abs-segs built with an aste/page table pair in the sst are 
@llowed to have page faults taken against them. 


The Bootload Command Environment within bootload Multics, 
that is, the collection of programs and facilities that make 
up a command level that allows certain critical functions to 
be performed before storage system activation occurs during 
system initialization. 


bootloead Multics 


cold 


These early parts of initialization that are capable of 
booting bce from a cold, bare machine, including bce itself. 


boot 
A bootload in which the state of ail hardware and peripher- 
als is) unknown. In particular, the Multics file system is 


either non-existant or has been destroyed. This is also 
Known as an initial boot. 
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collection 


A "sollection" is a set of programs read in as a unit that 
together perform a function during initialization. Collec- 
tions are referred to by number, starting with zero. Each 
collection depends on the mechanisms initialized by the 
collections that preceded it. As each collection finishes 
its task, some of that collection is deleted and some is 
kept, depending on the requirements of future collections. 


There are also fractionally numbered collections, which 
consist of support entities for the preceding collection. 


The division of initialization into collections is done 
based upon various restrictions imposed by the course of 
initialization. For example, since the first few collec- 
tions must run entirely within memory, restrictions. on 
available memory Cand the amount that can be required of a 
system) force unessential programs into later collections. 


contiguous 


cool 


crash. 


A contiguous segment is one whose memory locations describe 
contiguous absolute memory locations. Most segments do not 
have this requirement; their pages may appear arbitrarily in 
memory. Certain segments, though, such as the sst_seq must 
have their locations in order, due to hardware requirements 
for placement of their contents. 


boot 

A bootload in which the Muitics file system is on disk and 
believed to be good but in which the state of memory and 
ether peripherals is unknown. In particular, boot load 
Multics is not running. The mpc's may or may not have 
firmware running in them. The system is loaded from the MST 
(tape) and initiated via iom switches. 


A failure of Multics. This may be the result of a hardware 
or software failure that causes Multics to abort itself or 
the result of an operator aborting it. A crash of Multics 
during early initialization can produce a tape dump of 
memory. Crashes after this time can be examined with bce 
utilities or saved to disk by bce and analyzed later. 


deciduous segments 


These are segments generated or read in as part of 
initialization which are given branches in the hierarchy (by 
init _branches). Although they become part of the hierarchy, 
their pages remain in the hardcore partition and are 
therefore destroyed between bootloads. Examples are the 
segments in >slil and the Initializer's pds. (The name 
suggests the leaves of trees.) 
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deposit 
A page control concept, It means to add an object to a list 
of free objects. 


dseg 
descriptor segment (see data bases) 


dump 
A subset of Multics segments saved after a crash that can be 
examined through various dump analysis tools to determine 
the cause of the preceding crash. A dump is either a disk 
dump, a dump performed to tne dump partition of disk by the 
dump facility ef bee, or an "early dump", sone performed to 
tape during early initialization. 


early initialization ae 
Those parts of initialization needed to reach bootload 
Multics command level. All activities after leaving 
bootload Multics command level are referred to as service 
initialization. 


emergency shutdown 

A Multics operation, invoked by bce, that runs a subset of 
the hardcore facilities to shut down the file system (put 
the storage system into a consistent state) after a crash. 


esd 
emergency shutdown 

hardcore 
The supervisor of Multics, leosely defined. This isa 
collection of programs and segments generated or read in 
during initialization. 

hproc 


A hardcore process, Such a4 process is created by a call to 
create_hproc, as opposed to being created through the 
answer ing service. Such hprocs (currently 
SyserrLogger,Daemon and MCS_Timer_Daemon. SysDaemon) perform 
activities integral to the system operation and must be 
created prior to, and independent of, the answering service. 


init segments 
Segments needed only during the course of initialization. 
These are deleted after the end of the last hardcore 
collection. 


initialization 
The action of starting Multics. This consists of placing 
the appropriate software modules in the appropriate places 
and constructing the appropriate software tables such that 
an event, such as someone trying to dial a login line, or a 
page fault occuring, etc. will invoke the proper software 
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which will be in a position to perform the necessary 
operation. 


Kst 

known segment table (see data bases) 
lvt 

logical volume table (see data bases) 
MST 


Multics system tape 


Multics system tare 
The "tape" is the set of Multics programs that will make up 
the supervisor in un-pre-linked form. This set of programs 
originates on a tape; some of them spend part of their lives 
in a disk partition. 


nondeciduous 
A hardcore segment not mapped into the hierarchy. These 
segments live in the hardcore partition and are known only 
by having sdw's in the hardcore address space. 


partition 

An area of a storage system disk, ether than the label, 
vtoc, volume map and paging area. These areas can be 
accessed by paging mechanisms but are not used to hold pages 
ef storage system segments. Hardcore segments are mapped 
onto the hardcore partition so that they may be used, and 
early initialization can run, without touching the file 
system proper. 


pre-linking 

As the Multics supervisor is read from the MST, the various 
modules are linked together. This operation, called 
pre-linking, is similar te. linking (binding) that. occurs 
during normal service operation for user programs, except 
that it consists of running through all segments and finding 
all external references and resolving them. This is done 
during initialization for efficiency, as well as for the 
fact that the dynamic linker cannot be used to link itself. 


ptw 

page table word 
ptwam 

page table word associative memory 
pvt 


physical volume table (see data bases) 


root physical volume 
The main disk drive. It can never be deleted. This drive 
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is used to hold the original hardcore partition as well as 
the partitions required by bce and is therefore required at 
an early point in Muitics initialization. 


rpv 
root physical volume 
scas 
system controller addressing segment (see data bases) 
scs 
system communications segment (see data bases) 
sdw 
segment descriptor word 
sdwam 
segment descriptor word associative memory 
shutdown 
The orderly cessation of Multics service, performed such as 
to maintain consistency of the storage system. 
slt 


segment loading table (see data bases) 


supervisor 
A collection of software needed for operation of user's 
software and support software provided for the user. This 
would include software to make disk accessing possible, to 
provide scheduling activity, etc. The supervisor in Multics 
is referred to as "hardcore". 


temp segments 
Segments needed only during one collection. They are 
deleted at the end of the. major collection, before loading 
the next collection, 


uid 
unique identifier Cof a segment) 

unpaged 
A segment that is not paged under the auspices of page 
control. Such a segment has its page table either in 


unpaged_page_tables or int_unpaged_page_tables. Except for 
the possible presence of the breakpoint_page, these segments 
are contiguous. During early initialization, all segments 
are generated to be of this type. The program 
make_segs_ paged forms paged segments that are copies of the 
pagable initialization segments. Certain wired segments, 
though, are left unpaged. 
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vVtoc 


warm 


In previous releases, unpaged segments were literally 
unpaged, that is, they had no page table and had the unpaged 
flag set in their sdw, Currently only fault_vector, 
iom_mai lbox, dn355_mai loox, isolts_abs_seg, abs_seg and 
abs_segl are of this type but will receive page tabies in a 
future release. 


The volume table of contents of a storage system volume. 
The vtoc is divided into entries (vtoce), each of which 
describes a hierarchy segment contained on that volume. 


hoot 
A bootload in which the Muitics file system is present on 
disk and believed good, and in which bootload Multics is 


punning on the processor. This type of hootload of Multics 


is performed from disk. 


wired 


A page, or set of pages, is wired if it cannot be moved from 
memory by page control. 


withdraw 


A page control concept, said of records and vtoces. It 
means to remove an object from a list of free objects. 
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APPENDIX B 


INITIALIZATION AND INITIALIZED DATA BASES 


This appendix describes various. data bases kept by 
initialization or that are generated by initialization. As such, 
this list incorporates the most significant data bases within the 
system. 


AL LINKAGE {ACTIVE INIT LINKAGE) 


This initialization segment corresponds to area. linker for 
initialization programs that will be paged. This area is built 
by bootload_loader and segment_loader from linkage sections found 
on the MST. 


AS LINKAGE CACTIVE SUPERVISOR LINKAGE) 
This hardcore segment corresponds to area. linker for paged 
supervisor programs. It is shared across processes, and can 


therefore contain only per-system static such as initialization 
Static variables (when only one process is running) or system 
wide counters, etc. The linkage areas are formed in here by the 
various MST loading programs. 


BCE DATA (BOOTLOAD COMMAND ENVIRONMENT DATA) 


bce_data Keeps information that pertains to the command 
environment features of bootload Multics. It contains entries 
that describe the main pseudo i/o switches Cinput, output and 
error) as well as the state of exec_com and subsystem execution. 


BOOTLOAD INFO 
bootload_info, generated initially from bootload_info. cds, 
contains various information about the state and configuration of 


early initialization. It contains: the location of the bootload 
tape Ciom, controller channel, drive number and drive and 
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controller type provided by the IGM boot function), status about 
firmware loading into the bootload controller, the location of 
the rpv Ciom, controller, drive number and drive and controller 
type provided in the find rpv_subsystem dialog), the location of 
the bootload console (and type), a variety of pointers to other 
data bases, as well as the master flags indicating the presence 
of BOS and the need for a cold koot. All of this data is copied 
into sys_boot_info during generation and during system 
initialization. Most references to this data are therefore to 
sys_boot_info. 


bootload_info.cds has provisions to contain site-supplied 
configuration infermation. If these values are provided, no 
operator queries will be needed to bring the system up. Only 
cold site boots or disk problems would require operator interven- 
tion during boot. It is intended that an interface will ke 
provided to fill in these values, such that generate_mst could 
set the values into the segment and the checker could report 
their settings in the checker listing. 


CONFIG DECK 


Historicaily named, the config. deck contains the descrip- 
tion of the configuration. It contains one entry (card) for each 
iom, cpu, memory, peripheral subsystem, etc. in the configura- 
tion. It also describes various software parameters. These 
entries are referenced by programs too numerous to count. It is 
built initially by init_early_config to describe enough of the 
system to find the rpv and read in the real config_deck saved in 
a partition thereon. CIf this is a cold boot, in which there 
would be no config _deck, the config_.deck is entered manually or 
from the MST through the config deck editor.) After this time, 
it becomes a wired (at its initialization address) abs-seg mapped 
onto the "conf" partition. Various reconfiguration programs 
modify the entries. 


CORE MAP. 


Gne of the page control data bases, the core_map describes 
frames of memory available for paging. Each entry describes a 
page frame. When a frame is used (it has a ptw describing it), 
the disk address of the page occupying the frame is kept in the 
core_map entry. init_-sst initially builds the core_map. It is 
updated to accurately describe the state of pagable memory by 
make_segs_paged, which frees certain unpaged segments and 
collect_free_core which works to find various holes between 
segments. Page contrel maintains these entries. 
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DBM SEG (DUMPER BIT MAP SEG) 


dom.seg holds the dumper bit maps used by the volume 
dumper. It is paged off the hardcore partition. Its 
initialization as an area was performed by dbm_manSinit. Each 
configured disk drive has two maps here, one for the incremental 
dumper and one for the consolidated dumper. The segment starts 
with the usual lock, control information, and meters. After this 
comes an area in which the bit maps are allocated. Each bit map 
consists of a bit corresponding to each vtoce on the volume in 
question, The bits indicate the need to dump the various 
segments. 


DIR LOCK SES 


dir_lock_seq keeps track of lockings of directories and on 
processes waiting thereupon. It has a header with a lock and 
various status. Each dir_leck entry contains the uid of that 
which is locked, various flags, threads to a more recently locked 
entry, and the array of process ids for the various lockers (more 
than one only for all readers). 


DISK POST QUEVE SEG 


A part of page control, disk_post_queue_seg is an obscure 
data base used to keep track of disk i/o postings that could not 
be made because the page table was locked at the time of i/o 
completion. 


DISK SEG 


Tne disk seg contains the various tables Cexcept the pvt) 
used by disk_control and dectl to perform i/o to disks. It is 
split into the tables disk_data, disktab, chantab, devtab as well 
as the queue of disk i/o requests. disk_data contains entries 
giving the names and locations within disk_seg of the disktab 
entry for each configured disk subsystem. The disktab entry 
contains various subsystem meters, as well as holding the queue 
entries for the subsystem. Also contained herein are the chantab 
and devtab entries for the subsystem. Each chantab entry lists a 
ifo channel to use to perform i/o to the subsystem, given as an 
io_manager index. It also holds various per channel meters, and, 
most importantly, the dew list that performs i/o on the channel. 
The devtab entries, one per subsystem drive, describe the drives. 
This consists of status information (inoperative, etc.) as well 
as per drive statistics. 
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DM _ JOURNAL SEG_ 


A page control data base, dm_journal_seg_ is used to keep 
track of page synchronizstion operations for data management. It 
is allocated and initialized by init _dm_journal_seg. It starts 


with a lock for manipulating the journal entries as well as the 
usual wait event information. Also present are information about 
the number of pages held in memory, the maximum pages held, the 
number of journals, etc. Corresponding to each aste pool is a 
structure containing a threshold and number of active, 
synchronized segments. Following this are various meters. Then 
comes the journal entries and then the page entries. Each 
journal entry contains the time stamp that determines when pages 
of the segment being held can be written (when the journal was 
written), the number of pages held, and a relative thread to the 
list of page entries for the pages being held. A page entry 
contains the threads that make up this list, a relative pointer 
to the core map entry for the page, and a relative pointer to the 
journal entry for the page. 


DN3S5_ DATA 
This data seg, initialized by fnp_init, contains global 
information on each configured fnp. Data for each fnp includes: 


a pointer to the hardware mailbox, pointers to the dew lists and 
the physical channel blocks (pcb), the number of subchannels, the 


iom/ channel info, indexes into the pcb for Islas and hslas 
Chmics), status of the delay queues, various flags about the 
state of fnp operations, the ict (logical channel table) entry 
pointer, status of baotloading, and various counts of free 
blocks, input and output data and control transaction counts, 
etc, 

The dn3S5_mailbox is a set of mailboxes at fixed hardware 
addresses. They start with the fnp = pew. Also present are 


various counts of requests and the fnp crash data. Following 
this are 8 Multics initiated sub-mailboxes and 4 fnp initiated 
sub-mai lboxes. The sub-mailboxes describe the line for which the 
eperation is hkheing performed along with the data for that 
operation. 


DSEG (DESCRIPTOR SEGMENT) 


The descriptor segment is a hardware known data base. It 
contains a sdw (segment descriptor word) for each segment within 
a process' address space. The ultra important processer register 
dsbr (descriptor segment base register), also called the dbr, 
indicates the absolute address of the page table describing it. 
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The sdw of a segment indicates the address of the page table of 
the segment (which contain the locations of the pages of the 
segment} and other information, such as the length of the 


segment, accesses allowed, etc, dseg must be segment O. The 
initial dseg is generated by template_slt_ and copied into dseg 
by bootload_abs_mode. Entries are added by bootload_dseg, 


get_main and make_sdw as segments are loaded from the MST. The 
generation of sdws is integrated with the creation of silt 
entries, and the allocation of memory/disk that the sdw/page 
tables effectively describe. 


FAULT VECTOR (FAULT AND INTERRUPT VECTORS) 
This is another hardware known data base, at a fixed 
absolute memory address (0). It contains two words for each 


possible fault and interrupt. Normally, each entry contains a 
scu instruction, to store all machine conditions, and attra 


instruction, to transfer to the code that handles the 
fault/interrupt, These two instructions are force executed in 
absolute mode on the processor. The entries are filled in by 


bootload_faults and initialize_faults. During some phases of 
initialization, when a particular fault/interrupt is to be 
ignored (such as a timer running out), the fault vector entry is 
set to a scu/rcu pair, which stores machine conditions and then 
reloads them, returning to the point of interruption. The scu 
and tra instructions actually perform indirect references through 
“jits" pointers that are present following the interrupt vectors 
within this segment. During normal operations, only these 
pointers are changed. 


FLAGEOX 


The flagbox is an area of memory, at a known address, that 
allows communication between Multics operation and. bootload 
Multics. This area contains information from Multics to bootload 
Multics such as the fact that we are crashing, and here's what 
exec_com to run, Bootload Multics can pass information up when 
booting, such as being in unattended mede so that Multics will 
know how to boot. The area is examined by various programs and 
set through commands/active functions in both Multics and 
bootioad Multics operation. This area is within the bce tochold., 


INZR STKO CINITIALIZER STACK) 


This is the stack used by initialization and shutdown. The 
name stands for initializer stack. Originally wired, it becomes 
paged during initialization. Gnee the actual ring O stacks are 
created and after collection 3, initialization will leave this 
stack (Cin init proc). Shutdown will return to this stack for 
protection as the stack_O's are deleted. 
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LNT UNPAGED PAGE TABLES 


The page tables for init and temp segments are kept here. 
It gets an initial value through template_slt_ and is managed by . 


the various segment creation routines. Once make_segs_ paged is 
run, no unpaged segments exists whose page tables are here. So, 
we delete this segment. The page table for this segment is 


contained within it. 


18 CONFIG DATA 


The inter-relationship between peripherals, mpc's and icm's 
is described in io_config_ data. It contains a set of arrays, one 
each for devices, channels, centrollers and  ioms. Each entry, 
besides giving the name of each instance. of said objects, gives 
indexes into the other tables showing the relaticnship between it 
and the rest. (That is, for example, each device shows the 
physical channels going to it: each channel shows the mpc for it, 
etc. } 


19 PAGE TABLES 

The page tables referenced by a paged mode iom for iosi_ 
operations are found in iso_page_tables. It is a abs-wired 
segment, maintained by ioci_page_table. It starts with a leck and 


indexes of the start of free page table lists. The header ends 
with the size and in vuse flags for each page table. The page 
tables themselves are ecither 64 or 256 words long; each page 
table of length N starts at a 0 mod N boundary and does not cross 
a page boundary within the segment. 


IGIl_ DATA 

ioi_data contains information pertinent to isi_ (the i/o 
interfacer). It holds ioi's data itself (Cioi_data), as well as 
group channel and device entries for ioi handled devices. 
ioi_data contains counts of groups, shannelts and devices, 
reconfiguration lock, some flags, and then the channel, group and 
device entries. A channel/device group entry describes a group 
of devices available through a channel. It contains a lack, 


subsystem identifier, various flags describing the device group, 
the number of devices and some counters. A channel table entry 
describes the state of a channel. It holds status flags, the 
io_manager index for the channel, and a place for detailed 
status, A device table entry holds the wired information for an 
ioi device. Besides pointers linking it to the group and channel 
entries, it contains various status bits, workspace pointer, 
ring, process_id and event channels for communication with the 
outer ring caller, timeout and other time Limits, offsets into 
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the user's workspace for status storage, and the idcw, pcw, tdcw 
and status areas. 


16M_ DATA 


iom.data describes data in use by io_manager. It starts 
with  lpw, dew, scw and status area for stopping arbitrary 
channels. This is followed by various meters, such as 
invalid_interrupts. Following this, for each iom are various 
pieces of state information, cn-line, paged mode, etc. It 
concludes with more meters and ending with devtabd entry indices. 
For each device, a Status are is followed by various flags 
(in.use), channel identification, pew, lpw and scw, status queue 
ptr, and various times and meters. 


I6M_ MAILBOX 


This segment is another hardware known and fixed segment. 
It is used for communication with the various ioms. The segment 
is split into the imw area, which contains a bit per channel per 
iom per interrupt level indicating the presence of an interrupt, 
followed by the mailboxes for sending information to the ioms and 
receiving status back. 


KST (KNOWN SEGMENT TABLE) 


The Known segment table is a per-process segment that keeps 
track of hierarchy segments known in a process. Hardcore 
segments do not appear in the Kst. The kst effectively provides 
the mapping of segment number to pathname for a process, It is 
the keeper of the description of segments that are initiated but 
net active within a process (as well as those that are active). 
The Initializer's kst is initialized by init_root_dir. It starts 
with a header providing the limits of the Kst, as well as 
information such as the number of garbage collections, pointers 
to the free list, what rings are pre-linked, the 256k segment 
enable flag, a uid hash table, the kst entries and finally a 
table of private logical volumes connected to this process, Each 
kst entry contains a used list thread, the segment number of the 
segment, usage count per ring, uid, access information, various 
flags (directory, transparent usage, etc), an inferior count for 
directories or the lv index for segments and the pointer to the 
containing directory entry. It is this pointer that allows the 
name of the segment to be found. Also, the segment number of the 
directory entry pointer allows us to find the kst entry for the 
containing directory, etc., allowing us to walk up the hierarchy 
to find the pathname of a segment. 


B-7 AN70-01 


LVT (LOGICAL VOLUME TABLE) 


The logical volume table consists of an array of entries 
that describe the various logical volumes. It starts with a 
count of entries as well aS a maximum count limit. Following 
this is a relative pointer to the first entry and a hash table 
for hashing livid €logical volume ids) into lvt entries. The 
entries that follow, one per logical volume, contain a relative 
pointer to the threaded list of pvt entries for the logical 
volume, the livid, access class info for the volumes) and then 
various flags like public and readonly. It is initialized by 
initllvt to describe the riv and maintained by 
logical_volume_manager. 


The name_table contains a list of all of the various names 
by which the segments in the slit (see below) are Known. This 
table is used by the sit management routines but especially by 
the various pre-linkers, who use it to resolve references to 
initialization modules. It is generated from template_sIt_ and 
by the silt management routines, who read in the names from 
entries on the system tape. 


GC DATA 
oc_data describes data used by ocdcm_ to handle consoles, 


It starts with the required lock, version, device counts, etc. 
Various flags are kept, such as crash on recovery failure. The 


prompt, discard notice are kept here. Status pointers, times, 
etc. are followed by information on the process handling message 
re-routing. Following this are indices into queues of entries 


followed by the queues. An entry exists for priority i/o (syserr 
output, which always forces a wait until complete), one for a. 
pending read, and 8 for queued writes. After this are meters of 
ebscure use. The segment ends with an entry for each configured 
console followed by an entry for each element of a event tracing 
queue. Each console entry provides its name, State, type, 
channel, status, etc. Each i/o queue entry provides room for the 
input or output text, time queued, flags (alert, input/output, 
etc), and status. 


PHYSICAL RECORD BUFFER 
The physical_record_buffer is a wired area of memory used 


by collection O's and collection i's MST tape reading routine for 
ifo buffers. 
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PVT (PHYSICAL VOLUME TABLE) 


One of the disk describing tables, the physical volume 
table contains an entry for each configured disk drive. It can 
in some ways be considered the master disk describing table in as 
much as performing i/o to a disk drive requires the pvtx Cpvt 
index) of the drive (the index number of the entry in the pvt for 
that drive). The pvt entry contains the physical and logical 
volume id for the drive, various comparatively static flags about 
the drive Csuch as storage_system, being. demounted, 
device_inoperative, @etc.), information for the volume dumper and 
information about the size, fullness, volmaps and stocks (both 
record and vtoc) of the drive. This table is allocated by 
get_io_segs, and built by init pvt. The various brothers ina 
logical volume are chained together in a list by the 
logical_volume_manager so that the vtoc_man can have a set of 
disks from which to select a target for a new segment. During 
initialization, make_sdwSthread_ hcp (for init _root_vols) uses 
these threads (before the disk_table is accessed) to form the 
list of drives which contain hardcore partitions (those eligible 
to sontain hardcore segments). 


SCAS (SYSTEM CONTROLLER ADDRESSING SEGMENT) 

This is a very curious pseude-segment, built by scas_init 
out of page table words generated into scs. It contains one 
pseudo-page for each memory controller Cand another page for each 
individual store other than the lowest). The address of the page 
is the base address of the store/controtler. This segment makes 
references to it of the form nx1024 to form an absolute address 
to controller on. Thus, instructions like erser (read system 


controller register} can use this segment Cas indeed they do 
inside privileged_mede_ut) to reference the desired system con- 
troller registers. 


SCAVENGER DATA 

scavenger_data contains information of interest to the 
volume scavenger. Its header is initialized by 
init_scavenger_data. The segment starts with the usual lock and 
wait event. Following this is the pointer to the scavenger 
process table. Then come the meters. The scavenger process 
table, which follows, describes the processes performing 


scavenging operations. Each entry contains a process id of a 
scavenging process, the pvtx of the drive being scavenged, and 
indices of scavenger blocks in use. Scavenger blocks contain 
record and overflow blocks used to Keep track of pages of a disk 
Cits claiming vtoce and its state). 
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SCS (SYSTEM COMMUNICATIONS SEGMENT) 


The scs is a hodge-podge of information about confiquration 
and communication between active elements. It contains informa- 
tion about the scus and the cpus. It contains the cow's (connect 
operand words) needed to connect to any given cpu/iom, the 
interrupt masks used to mask/unmask the system, the various smic 
patterns (set memory interrupt cells), instructions to clear 
associative memories and the cache, connect and reconfiguration 
locks, various trouble flags/messages used for keeping track of 
pending communication of faults to bce, cyclic priority switch 
settings, port numbers for controliers, configuration data from 
the controllers, processor data switch values/masks, controller 
sizes, and the scas page table (see scas). 


SLT (SEGMENT LOADING TABLE) 

Gne of the most significant initialization data bases, the 
slt describes each initialization segment. It is built initially 
from template_slt_, an alm program that not only builds the 


appropriate slt entries for collection 0 segments, but also 
generates the dseg for collectian 0. Esch entry in the sit 
contains: pointers into name_table of the names and the final 
storage system pathname (and acl), if any, for the segment; 
access modes, rings, etc. for the segment; various flags used 
for generation/ loading of the segment, such as 
abs/init/temp/supervisor segment, wired/paged, etc.; the length 
and bit_count, etc. It is maintained by bootload_slt_manager and 
slt_manager, who build entries based on information on the MST. 
These entries are maintained so that the varicus pre-linkers 
{hootload_linker and pre_link he) can find the target segments of 
the various references. 


The sst (which contains the active segment table) is one of 
the most important tables in Multics. It is the keeper of active 
segments. Each active segment has an entry describing it Cits 
aste). The aste contains information used by segment control and 
communicated with page control on the state of a segment. The 
most important part of the entry is the page table words (ptws) 
describing the disk/memory location of each page. There are four 
pools of astes of different lengths to hold page tables of four 


possible maximum lengths: 4, 16, 64 and 256 ptws. The entries 
are threaded into various lists, The free entries of the various 
pools are threaded into lists. Active segments have their own 


lists. Separate lists are generated for temp and init (supervi- 
sor) segs. Aside from these threads, each aste also contains 
threads used to link segments to their parents and their trailer 
seg entry. Status information includes: the segment'’s uid, the 
current length, maximum length and recerds used, the pvtx and 
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vtocx of the segment (which couple with the ptws to find the 
pages of the segment), various status bits of more obscure use, 


and finally the quota computation information. init _sst origi- 
nally builds this table. The page table words are maintained by 
page control. The entries themselves are maintained by segment 
control. 

SST_ NAMES _ 

The sst_names_ segment contains the names of paged segments 
described by the sst. It is initialized by init _sst_name_seg 
during collection 2 and maintained by segment control only if the 
astk parm appears. It starts with information describing the. 


four aste pools followed by the paged segment primary names. 


STACK 0 DATA 


stack_O_data contains information keeping track of the ring 
O stacks (stack_O.nnn) that are shared between processes (one per 
eligible process). It is initialized by init_stack_0O. It has a 
lock used to control threading of a pool of such stacks. Each 
entry contains a list thread, a relative pointer to the aste for 
the segment, a relative pointer to the apte for the holding 
precess, and the sdw for the stack. When this stack is given to 
a process, this sdw is forced into its dseg: the acl of the stack 
is kept as a null acl. 


STOCK SES 


stock_seg contains the record and vtoce stocks, a part of 
the reliable storage system. Whenever a new page or vtoce is 
needed for a drive, it is obtained from these stocks. The stocks 
are filled by pre-withdrawing a@ number of records or ytoces from 
the drive. This mechanism is used so that, upon a crash, it is 
guaranteed that any records or vtoces being created were marked 


in the record or vtoc maps as in use. This prevents re-used 
addresses. 
STR SEG (SYSTEM TRAILER SEGMENT) 

The str_seg is a paged segment used by segment control to 
perform setfault functions. It is initialized into a list of 
free entries by init str_seg. Each entry contains the usual 


backward and forward threads forming a list of trailers for a 
given segment (the list itself is found by a relative pointer in 
the aste for the segment). When needing to fault a segment, this 
list shows all processes containing the segment. The entry shows 
the segment number, for a process with this segment active, of 
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the segment and arelative pointer to the aste for the dseg of 
that process (which is where we need to fault the sdw). 


SYS_ INES 


sys_info is a Keeper of all sorts of information about the 
state of the system, The most important entries to 
initialization are sys_infoSinitialization_state, which takes on 
values of 1, 2, 3 and 4 correspsnding to whether we are running 
initialization collection 1, 2, 3 or whether we are running 
service (beyond cellection 3}, and sys_infotcoliection_i_phase, 
which takes on values defined in collection_1_phases. incl. plt 
corresponding to running early, re_early, boot, bce_crash, ser- 
vice and crash passes through collection 1. Also included are 
key things like: the scu keeping the current time, the current 
time zone, various limits of the storage system, and some ips 
signal names and masks. The variable "max_seg size" records the 
maximum length of a segment. This value is changed during bce 
operation to describe the maximum length of a bce paged temp 
segment. This allows various Multics routines to work without 
overflowing segments. Also in sys_info is “bce_max_seg_ size", 
this bce maximum segment length. This is available for any user 
ring programs who desire to limit the size of objects they 
prepare for the bce file system. 


SYS_ BOOT INFO 


See bootload_info, above. 


SYSERR_ DATA 

The syserr_data segment is part of the syserr logging 
mechanism.  syserr actually just writes messages into this 
segment and not to the paged log ts avoid problems of paging 
during possible system trouble. It is up to the syserr hproc to 


move these messages from syserr_data to the log. 


SYSERR_ LOG 


The paged abs-seg syserr_log, which describes the log 
partition of disk, is used to hold the syserr log. It is mapped 
onto the log partition by syserr_log_init. The syserr mechanism 
involves putting syserr messages into syserr_data (which are 
possibly written to the console) and then waking up the syserr 


hproc which copies them into the paged partition. This is done 
so that page faults are taken by the hproc, not by the syserr 
caller who may be in trouble at the time. It starts with a 


header providing the length of the segment, a lock, relative 
pointers to the first and last messages placed there and alse 
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copied out (by the answering service), the threshold that shows 
how full the partition can get before the answering service is 
notified to copy out the messages, the event channel for 
notification Cof the answering service) and the event for 
locking. Following this are entries for the various syserr 
messages. Each message is threaded with the others; it has a 
time stamp, id number, and the text and optional data portions of 
the message.. 


Te_ DATA 


tc_data contains information for the traffic contrellier. 
The most obvious entry list herein is the tlist of aptes (active 


process table entries). There is one apte for every process. 
The apte lists activation information for the process, such as 
its dbr., its state (blocked/running/stopped/etc.), var ious 
per-process meters (such as cpu usage), its work class, and other 


per-process scheduling parameters. Following the apt is the itt 
(inter-process transmission table), maintained by pxss (the 
traffic controller) to hold wakeups not yet received by a target 
process. The call to hecs_Swakeup (or its pxss equivalent) places 
an entry in the itt containing the target process id, the event 


channel, the message data, etc. The next call to 
hes_$read_events obtains the events waiting for the target 
process, Also present in tc_data is various meters (tem. inel1) 
and other flags. Imbeded within this is the wet (work class 


table) which keeps track of the status of scheduling inte work 
classes, tc_init builds these tables (see tc_data_header). 


T¢_ DATA HEADER 


This is a trick initialization segment. tc_data_header is 
allocated wired storage by tc_init to hold the real te_data. 
tc_data, originally build just from a cds segment and therefore 
just describing the header of tc_data, is copied in. The sdws 
for tc_data and tc_data_header are then swapped. As such, the 
initialization segment tc_data_header (which describes the read 
in tc_data) is deleted, but tc_data (now mapped onto the 
allocated tc_data_header areca) remains. 


TSEHSLD 
The toehold is another area for Multics/bootload Multics - 
communication. CIN particular, the flaghox is contained within 


it.) The toehold is a small pregram capable of getting to 
bootload Multics from a crashing/shuting down Multics service. 
(Its name is meant to suggest holding on by one's toes, in this 
case to bootload Multics.) init_toehold builds a dew (device 
control word) list that, when used by the toehold program, can 
write the first 512k of memory (those used by boeotload Multics) 
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out to the bce partition and read in bootload Multics (saved in 
the bce partition by init _toehold). The program runs in absolute 
mode. It is tisted here because it contains the flagbox and the 
all important dew lists. 


ITY AREA 
Terminal control blocks (tcb's) are allocated in tty_area., 


It is initialized to an area by fnp_init and managed by the 
various communication software. 


TTY BUF 

The tty_buf segment contains, obviously enough, the tty 
buffers used for manipulating data communicated with the fnp. It 
contains various meters of characters processed, number of calls 
to various operations, echo-negotiation, etc., trace control 
information and timer information. Following this is the 
tty_trace data, if present, and the tty_buffer_block's, split 


into free blocks and blocks with various flags and characters in 
chains. The layout of this segment into empty areas is done by 
fnp_init. 


ITY TABLES 
tty_tables is an area in which tables (conversion and the 


like) are allocated. It has the usual lock and lock event. It 
is initialized by fnp_init. 


UNPAGED PAGE TABLES 

All permanent non-per-process unpaged segments. have their 
page tables in unpaged_page_tables. The page table for this 
segment is also within it. It is generated initially by 


template_slt_ and added to by the various segment creation 
routines. The header of unpaged_page_tables contains the abso- 
lute address extents of all hardcore segments that contain page 
tables; these are unpaged _page_tables, int_unpaged_page_ tables 
and sst_seg. Dump analyzers look here to resolve absolute 
addresses from sdws into virtual addresses of page tables. 


VI6C BUFFER SEG 


¥toc buffers live in the vtoc_buffer_seg. The segment is 
allocated and initialized by init _vtoc_man. It starts with the 
usual global lock and wait event. Following this are various 
parameters of the amount and usage of the vtec buffers, including 
information about the vtoc buffer hash table. Then comes the 
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vtoc_man meters. Finally comes the hash table, the vtoc buffer 
descriptors (pvtx - vtocx info, etc, ) and the vtoc buffers 
themselves. 


WI LINKAGE (WIRED INIT LINKAGE) 
This initialization segment corresponds to area. linker for 


wired initialization segments. It is built by the MST loading 
routines. 


WIRED HARDCORE DATA 
Another collection of data for hardcore use, this segment 
is permanent, It contains the size of a page, the amount to wire 


for temp-wiring applications, the history register contral flag, 
the trap_invalid_masked bit, a flag specifying the need for 
contiguous i/o buffers Cif a non-paged iom exists), the debg card 
options, the fim fault _counters and the bce abort_request flag. 


WS_ LINKAGE (WIRED SUPERVISOR LINKAGE) 


This wired hardcore segment, shared between processes, 
corresponds +o area. linker for wired hardcore programs. It is 
buiit by the MST loading routines. 


B-15 AN70-01 


APPENDIX C 


MEMORY LAYOUT 


In the memory layout charts below, the starting absolute 
address and length for each data area is given (Cin octal). When 
a number appears in brackets ([]), this means that it is really a 
part of the segment listed above it. 


The memory layout after the running of collection O (the 
loading of collection 1) follows. 


start length contents 
0 600 fault_vector 
1200 2200 iom_mai lbhox 
3400 3000 an355_ mailbox 
10000 2000 bos_toehold 
12000 10000 config. deck 
24000 22000 bound _boot Load_O 
[24000] {4000} [{bootioad Multics) toeholdl 
[24000] [2000] [flagbox foverlays the toehold)] 
[30000] Cn] [bootload_ ee 
46000 | 4000_——=n . toehold data 
52000 2000 unpaged _page_tables 
54000 2000 int_unpaged_page_tables 
56000 2000 breakpoint_page 
60000 6000 physical_record_buffer 
66000 2000 dseg 
7o000 10060 name_table 
{00000 4000 sit 
104000 2000 lot 
106000 and up wired segments 
fabricated segments 
1777777 and down all other segments 
The absolute addresses of most of these segments is 
arbitrary. Hardware Known data bases must be at their proper 
places, though; also, the tochotds are placed at addresses known 
to operators. Except for these exceptions, the segments may be 


moved, Their addresses are contained in boottoad_equs. incl. aim, 
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All programs refering to this include file must be reassembled if 
these addresses are changed. Certain interdependencies exist 
that one must be aware of. First of all, the toechold is placed 
at a O mod 4 page address. physical_record_buffer must be the 
last of the fixed memory address segments. The length of all 
segments is an integral number of pages. The two unpaged page 
tables segments must be large enough to meet the demands on then: 
refer to announce_chwm. Also, the length given for 
bound_bootload_0 must hold the text thereof. 


After collection 1 has finished, segments have been made 
paged and collection 1 temp segments have been deleted, the 
memory layout is as follows. 


start length contents 
(9) 600 fault_vector 
1200 2200 iom_mai lbeox 
3400 3000 dn355_mai lbeox 
170000 2000 bos_toehold 
12000 10000 config_ deck 
24000 4060 tochold (bootload Multics) 
[24000] £2000] [flagbox (overlays the toehold)] 
46000 4000 toehold_data 
»2000 2000 unpaged_page_tables 
56000 2000 breakpoint _page 
60000 and up paging area 
high mem sst_seg 
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aborting bce requests 
see bce, aborting requests 


abs-seg 3-10, 3-13, 3-16, 

3-17, 3-18, 3-19, 4-3, 
4-5, 4-16, 4-18, 6-8, A-1, 
B-2 


absolute mode 2-2 
accept_fs_disk 6-3 
accept_rpv 


6-3, 8-14 


active init linkage 
see ai_linkage 


active segment table 
see sst 


active supervisor linkage 
see as_ linkage 


ai_linkage 2-7, 3-20, B-1 

announce_chwm 3-8 

appending simulation 4-4 
see also bce_dump and 


bce_probe 


area. linker 
see linkage sections 


assume_config deck 2-7 


as_linkage 


bce 


aste pools 3-12, B-10 


2-7, 3-20, B-1 
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4-11 
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area usage 4-2 
command level 4-10, 4-15 


bce_crash 3-2 
boot 3-1 
crash 3-1 
early 3-1 
command processing 4-2, 4-9, 
4-11 
communication with Multics 
B-5 
config deck manipulation 
4-17 
data B-1 
disk accessing 4-3, 4-16 
error reporting 4-2, 4-8 
exec_com 4-93 
facilities 4-1 
file system 3-16, 4-3, 4-16, 
4-18 
firmware 
loading 4-10 
ifo switches 4-2, 4-7, 4-18, 
B-1 
initialization 4-1, 4-18 
invocation upon a crash 
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bce (cont) 
machine state 5-2 
paged programs 3-16 
partitions 


creation 


3-6, 3-9, 3-13 


usage 3-16, 4-1, 


4-3, 


4-16, 4-17, 4-18 
probe 4-7, 4-8, 4-10, 4-11, 
4-14, 4-15 
current address 
4-14 
question asking 4-2, 4-14 
ready messages 4-15 


4-13, 


reinitialize 


request processing 4-2, 4-6 


4-10 


request table 4-15 
restrictions 4-3 
temp segments 4-3, 4-17 


bce_abs_segq 4-4 
bce_alert 4-4 
bce_almdie 4-4 


oce_appending_simulation 
4-8, 4-14 
bce_check_abort 4-6 
bce_command_processor,_ 4-6 
bce_console_io 4-7 
bce_continue 4-7. 
bce_crash bce command level 
see bce, command level, 
bce_crash 
bce_data 4-7, B-1 


bce_die 4-7 


4-4, 


bce_display_instruction_ 
bce_display_scu_ 4-8 
bce_dump 4-8 

bce_error 4-8 


bce_esd 4-9 


4-7 


i-2 


bce_execute_command_ 4-3 


bce_exec_com. 4-39 
bce_exec_com_input 4-3 


bce_fwload 3-16, 4-10 


bce_get_flagbox 4-10 
pce_get_to_command_level 
bce_inst_length. 4-190 
bce_listen_ 4-11 
bce_ltist_requests_ 4-11 
bce_map_over_requests_ 4-11 
bce_name_to_segnum_ 4-11 
bce_probe 4-11 

see also bce, probe 


bce_probe_data 4-14 
bce_query 4-14 
bce_ready 4-15 


bce_relocate_instruction_ 


4-10 


4-15 
bce_request_table_..4-15 
bce_severity 4-15 
bce_shutdown_state 4-15 
bce_state 4-16 
boot 

cold 3-13, 6-4, 6-7, A-1 
cool A-2 

from bce 4-10 

from BOS 2-71 

from disk A-6 

from iom 2-1 

from tape A-2 

initial A-1 

warm A-6& 
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boot bce command level 


see bce, command level, boot 


bootload command environment 
see bce 


bootload command environment 
data 
see bce_data 


bootload Multics 
bootload_O 2-3 
bootload_1 3-8 
bootload_abs_mode 2-2 
bootload_console 2-4 
bootload disk post 4-16 
boot load_dseg 2-4, 8-1 
bootload_earty_dump 2-5 
beootload_error 2-5 
bootload_ faults 2-5 


bootload_file_partition 4-16, 


4-138 
bootload_flagbox 2-6 
bootload_formline 2-6 
bootload_fs_ 4-16 
bootload_fs_cmds_ 4-17 
bootload_info B~1 
beotload_io 2-6 
bootload_linker 2-7 
bootload_loader 2-7, 8-1 
bootload_qedx 4-17 


bootload_sit_manager 2-7 


i-3 


bootload_tape_fw 2-8 


bootload_tape_label 2-1, 8-1 


boot_rpv_subsystem 3-8 
becot_tape_io 3-8 
Bos 


getting to from bce 
presence of 2-7 


4-7 


bound _bootload_O 2-1, 8-1 
breakpoints 3-15, 3-16, 3-17, 
4-12, 4-13, 4-14, 5-2 
see also breakpoint_page 


breakpoint_page 2-7, 3-9, 
3-16, 3-17, 3-18, A-5 
see also breakpoints 


Cc 


central processor 
see cpu 


channel table entry 7-2, B-6) 
chantab B-3 


clock 
setting 3-12 


cold boot 
see boot, cold 


collection 1-1, A 

collection O 1-2, 
console support 
data B-1 
error handling 2-5 
input/output 2-6 
interrupts 2-6 
main driver 2-3 
programming in 


-2 
2-1 
2-4 


2-2 


1-2, 3-1 
3-2, 3-7 


collection 1 
bce_crash pass 
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collection 1 (cont) 
boot pass 


sequence 3-2 


bootload Multics pass 3-1 
crash pass 3-1, 3-7 
early pass 3-1 

sequence 3-5 
passes summary 3-1 
re_early pass 3-2, 3-7 


see also bce 

service pass 
sequence 

shut pass 


3-1 
3-4 
3-1, 3-7 
collection 2 1-3. 

loading 3-20 

pre-linking 3-18 

sequence 6-1 


collection 3 1-3, 77-1 


collection_1l_phase B-12 
collect_free_core 3-9 


conditions 
signalling 3-15 


configuration 
data 
see config deck and scs 
initialization sequence 
8-11 
memory 8-5 


config deck 3-10, B-2 
changes to 4-10 
editing 4-17 


initial generation 3-12 
setup 3-5 
config deck_data_ 4-17 
config deck_edit_ 93-10, 4-17 


connect operand words 3-20 


console 
collection 0 2-4 
driver 
see ocdcm, 
locating 2-4 


i-4 


contiguous A-2 
cool boot 
see boot, cool 


core high water mark 3-8 


core_map 3-14, 3-17, 8-13, 
B-2 


cow 
see connect cperand words 


cpu 
data B-10 
description 68-4 
initialization of data 
starting 6-93, 7-3 


3-20 


crash A-2 
early in 
handtier 
handling 
image 

access 4-4 

restarting 4-7, 5-2 
machine state 5-1 
memory saving 5-1 
memory state B-13 
memory swapping B-13 


initialization 5-1 
3-1, 3-3 
1-4, 5-1 


crash bce command level 
see bce, command level, 
crash 
create_root_dir 6-4 


create_root_vtoce 6-4 


create _rpv_partition 3-9 
cte 
see channel table entry 


data 
about 
about 
about 
about 


active segments B-10 
bce B-1 
bootload tape B-1 


collection 0 B-1 
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data (cont) 
about configuration 
see config _deck and sc¢s 
see io_config_ data 
about core frames B-2 
about cpus B-10 
about hardcore segments 
. B-10 
about processes 8-13 
about rpyv B-2 
about storage system B-i2 
about system controllers 
B-10 
about system state B-12 


data bases B-1 
dbm_man 6-4 


dem_seq 6-4, B-3 


der B-4 
deactivate_for_demount 9-4 
deciduous segments 

see segments, deciduous 


delete_seqs 3-9 
demount_pvy 9-5 
deposit A-3 


descriptor segment 
see dseg 


descriptor segment base 
register 
see dbr 
device table entry 7-2, B-6 
devtab B-3 


directory 
locking B-3 
dir_lock_init 6-4, 8-14 


dir_lock_seg 68-4, B-3 


i-5S 


disk 
accessing 3-19, A-1, 
ifo posting B-3 
storage system 
acceptance 6-3 
demounting 9-5 


B-3 


disk queue B-3 
disktab B-3 
disk _ data B-3 
disk_emergency 9-5 


disk_post_queue_seg B-3 


disk_reader 3-983 

disk_seg 3-11, B-3 
dn_journal_seg. 6-65, B-4 
dn355_data B-4 
dn355_mailbox 6-5, B-4 


dseq 2-8, 3-17, A-3, B-4 


dte 
see device table entry 


dump 
early 2-5, A-3 
to disk 4-8, A-3 
to tape A-3 


dumper bit map seg 
see dbm_seg 


early bce command level 
see bce, command level, 
ear ly 


early initialization 
dumps 2-5 
see initialization, early 


emergency shutdown 4-9 
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emergency shutdown (cont) 


see shutdown, emergency 
emergency_shutdown 9-5 
errors 

handling 


in bce 3-14 

in collection O 2-5 
reporting 

bce 4-8 

syserr B-12 
see also failures 


esd ; 
see shutdown, emergency 


establish_config_deck 3-10 
establish_temp_segs 4-8, 4-17 


interrupt cell 
8-38 


execute 
register 


execute 
register 


interrupt mask 
8-3 


failures 
of boot initialization 
of Multics A-2 
of service initialization 
3-2 
see also errors 


37-2 


fast connect code 3-18 


fault vector 2-5 
see also vectors 


fill _vol_extents_ 3-10 
fim 5-2 
find _file_partition 4-18 


find rpv_subsystem 3-10 


firmware 
loading 
general mpcs 
in bce 4-10 
into boot tape controller 


3-71 


2-8 
non-bootload disk mpcs 
3-3, 3-16 


rpv disk mpc 3-6, 3-8 
location 4-10 

for boot tape mpc 2-3 
naming 2-3 


flagbox B-5 

management... 2-6, 4-7, 4-10 
fnpLinit 6-4 
fsout_vol 9-6 

G 

gates 

initialization 6-6 

linkages 8-15 
getuid 6-5, 8-14 
get_io_segs 3-11 
get_main 3-11, 8-2 


group table entry 7-2, B-6&.- 


gte 
see group table entry 


hardcore A-3, A-5 
address space 6-1 


hardcore partition 
accessing 3-138 
allocation from 3-17, 6-3 
amount of utilization 6-3 
lecating 3-13 
usage 6-8, 8-2, A-2, A-4 
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hardcore segments 
creation 8-1 
numbering 6-8, 8-15 


hardware 
- configuration 8-5 
inter-conmnection 8-3 
inter-module communication 
8-7 
hic_load_mpc 3-171 


hproec 6-10, A-3 


idle loop 6-7 
‘idle process 6-9, 6-10, 8-16 


3-9 
init 


init segments 
see segments, 
initialization A-3 
bce 4-1, 4-18 
boot failure 3-2 
configuration 8-3 
sequnce 8-11 
directory control 
disk control 3-3 
early A-3 
file system 
gates 6-6 | 
hardware 8-3 
linking of A-4 
page control 
pl/1 environment 
rpv 3-14 
scu 3-14 
segment control 6-1, 
service failure 3-2 
storage system 6-1 
summary 1-1 
traffic control 
8-16 


6-1, 


1-3 


1-2 


8-14 


a 2l;--6*15 


initialization _state B-12 


initializer 93-15 


8-14 


1-2, 3-3, 8-13 


initializer stack 
see stack, initialization 


initialize faults 3-15, 6-3 
initialize_faults_data 3-15 
initial _error_handier 3-14 
init_aste_pools 3-12 

init_ bce 4-18 
init_branches 6-5, A-2 
init_clocks 3-12 
init_dm_journal_seg 6-6 
init_early_config 3-12 
init_empty_reet 3-12 


init_hardcore_gates 6-6 


init_he_part 3-13 

init_lvt 6-6, 8-14 
init_partitions 3-13, 8-14 
init_proc 7-1 
init_processor 6-6, 8-16 
init_pvt 3-13, 8-13 
init_root_dir 6-7, 8-14 
init_root_vols 3-13, 8-13 


init_scavenger_data 6-7 
init_scu 3-14 
init_sst 3-14, 8-13 
init_sst_name_seg 6-7 
init _-stack_O 6-7 


init_str_iseg 6-8, 3-14 
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init_sys_var 6-8 


init_toehold 5-1, 5-2, B-13 


init_volmap_seg 6-8 


init.vol_header 3-14 


init_vtoc_man 6-9, 8-14 
input/ output 
in collection 0 2-8 


inter-process transmission 
table 
see itt 


interrupt mask assignment 
register 8-9 


interrupt vectors 
see vectors, interrupt 


interrupts 
collection 0 2-6 
mask assignment 8-3 
mask operations 8-10 
mask values 8-11 


int_unpaged_page_ tables 
see segments, unpaged 


inzr_stko 


see stack, initialization 


ioi. 7-2 


ioi_data 3-11, B-6 
ioi_init 7-2 
ioi_page_table 7-3 


iom 
description 8-4 


iom_data 3-11, 3-16, B-7 
iom_data_init 3-16, 8-11 
iom_mailbox B-7 


io_config_data 3-11, 7-2, B-& 


* load_disk_mpcs 


io_config_init 7-2 


io_page_tables 
see page tables, 
iom 


paged mode 


itt B-13 


known segment table 
see kst 


kst 6-9, 8-14, A-4, B-7 


Kst_util 6-9 


ict B-4 


linkage sections 
B-1, B-15 
hardcore gates finding 6-6 


2-7, 3-20, 


linking 
see pre-linking 


loading 
of collection O 
Of coallection 1 
of collection 2 
of collection 3 
3- 


load_mst. 3-16 
load_system 7-3 


locking 
directories 6-4 


logical channel table 
see lct 


logical volume table 
see lvt 
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lvt 6-6, 8-14, A-4, B-8 


M 


mailboxes 
datanets B-4 
iom 3-16, B-7 
mnake_sdw 3-16, 3-21, 8-2 
make_segs_paged 3-17, A-5, 
B-6 


memory 
accessing A-1 


allocation 3-11 

allocation from silt 3-3, 
3-11, 8-2 

extent of usage 3-3 


freeing 3-93, 3-17 
layout A-2 
after collection 0 C-1 
after make_segs_ paged C-2 
announcing 3-8 
placement 3-17 
required placement C-1 
paging use 3-9 
requirements for bootload 
3-4 
move_non_perm_wired_segs 3-17 
MST 3-16, 3-20, A-4 
disk reading 3-93 
tape reading 3-8, 3-21 


multi-programming 6-10 


Multics system tape 
see MST 


name_table 2-8, B-& 


nondeciduous segments 
see segments, nondeciduous 


i-9 


6 
ecdcm 3-18, 4-6, 4-7 
data B-8 
oc_data B-8 


see also ocdem_, data 


page table word 
see ptw 


page table word associative 
memory 
see ptwam 


page tables 
absolute to virtual 
addresses B-14 
active segments B-10 
paged mode iom 7-2, 8-6 
scas B-10 
see also unpaged page tables 
unpaged segments 
see segments, unpaged 
paging 
of bce segments 3-16, 4-1 
eof initialization segments 
3-17 
partition A-4 
see bce, partitions 
see hardcore partition 


pathname associative memory 
6-7 


physical volume 
see disk 


physical volume table 


see pvt 
physical_record_buffer B-8 
pll environment 
setup 3-8 
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prds_init 3-18 


pre-linking 2-1, A 
initialization A 
of collection 
of collection 
of collection 


N= oO 
enh 
~ alo 


pre-withdrawing 
pre_link_he 3-18 


probe 


see bce, probe 4-7 


ptw A-4 
ptwam A-4, A-5 


pvt 3-13, 8-13, A-4, 


read_disk 3-19, 8-13 


read_disk_label 3-19, 8-13 
read_early_dump_tape 2-5 
real_initializer 3-19 


reinitialize 4-10 


reload 7-1 


request tabie 

see bce, request table 
ring 1 command level 7-1 
root dir 


activation 
creation 


6-7 
6-4, 6-7 


root physical volume 
see rpv 


rpov A-5S 
initialization 
layout 3-10 


3-12 


rpv (cont) 
locating 3-10 


$s 


safe_config_deck 3-3 
salvaging 6-3, 6-5, 6-8 
save_handler_mc 5-2 
scas 3-20, A-5, B-9 
scas_init (3-20 
scavenger 9-6 
scavenger_data 6-7, B-3 
secs 3-20, A-5, B-10 


scs_and_clock_init 3-20, 


SCU 
addressing 8-6 
data B-10 


description 8-3 
initialization of data 
register access B-39 


sdw 
creation 


2-4, 8-2, A-5, B-4 
3-16 


segment descriptor word 
see sdw 


seqment descriptor word 
associative memory 
see sdwam 


segment loading table 
see sit 


segments 
activation 
deactivation 
deciduscus 
9-4, A-2 

hardcore 
data B-10 


information 
9-4 


i-10 


6-5, 8-3, 8- 


B-7 


15, 
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segments (cont) 
hardcore 
permanent 
numbering 8-15 
hierarchy 
numbering 8-15 
init 3-9, A-3 
numbering 8-15 
nondeciducous A-4 
number ing 
Fixed 8-15 
euter ring B-7 
synchronized 6-6, B-4 
temp 3-9, A-5 
numbering 8-15 
unpaged A-5, B-6, B-14 


segment_loader 3-20 
setfault B-11 


shutdown 93-1, 93-6, A-5 
emergency 4-9, 9-3, 9-5, 
A-3 
part 1 9-2 
normal 9-7 


shutdown_file_system 9-7 
shutdown_state 9-6 


sit 2-7, 2-8, 3-21, A-5, B-8, 
B-10 
memory allocation from 
see memory, allocation 
' from silt 


slt_manager 3-21 


sst 3-14, 3-17, 8-13, 8-14, 
B-11 


sst_names_ 6-7, B-11 


stack 
collection 0 2-2 
initialization B-5 
ring O 6-7, B-11 
segment numbering 8-15 
shutdown 9-4, 9-6, 9-7, B-5 


stack_O_data B-11 


i-11 


Start_cpu 6-3, 8-16 


stocks 3-11, 8-13, 9-6, B-@, 
B-11 


stock_seg B-11 
stop on switches 3-20 
str_seg 6-8, B-11 


supervisor 
see hardcore 


switches 
i/o 
see bce, i/o switches 


switch _shutdown_file_ system 
9-7 


synchronized segments 
see segments, synchronized 


syserr_data B-12 
syserr_log 6-8, B-12 
syserr_log_init 6-9 


system communications segment 
see scs 


system controller 
see scu 


system controller addressing 
segment 
see scas 


system segment table 
see sst 


system trailer segment 
see str_seg 


system_type 2-7 
sys_boot_info B-1 


sys_info B-12 
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sys_infoSbce_max_seg_size 
4-18 


tape_reader 3-21 
tcb B-14 

tc_data 3-21, B-13 
tc_data_header B-13 


tc_init 3-21, 6-105, 7-3, 8-16 


tc_shutdown 9-7 


temp segments 3-9 
see segments, temp 


template_slt_ 2-8, 8-1, 
B-6, B-8, B-10, B-14 


B-5, 
terminal control blocks 
see tcb 


toehold 2-5, 5-1, 
entry points 5-1 


8-1, B-13 


traffic control 
data B-13 
initialization 
see initialization, | 
traffic control 
shutdewn 9-7 


tty_area 6-4, B-14 


tty_buf 6-4, B-14 


tty_tables 6-5, B-14 


uid 6-5, 8-14, A-5 


unique identifier 
see uid 


i-12 


unpaged page tables 2-7, 2-8, 
3-8, 3-11, 8-2 


unpaged segments 


see segments, unpaged 
Vv 
vectors 
fault B-5 


initialization 3-15 
collection 2 6-9 

interrupt .B-5 

see also fault_vector 

setup 2-5 


volmap_seg 6-8 


volume table of contents 
see vtoc 


¥toc A-& 
accessing 6-8 
updating 9-5, 9-6 


vtoce A-6 
accessing 6-3, 6-9, 8-14 
buffers 6-9, 93-7, B-14 
creation 
deciduous segments 
8-3 , 
initial 3-14 
root dir 6-4. 
deactivation 93-5 
dumper bit B-3 
scavenger B-9 
specifying number 3-13 
stock 9-6, B-S3, B-11 
updating 6-8, 9-1, 9-4 
updating for partition 
creation 3-9 


6-5, 


vtoc_buffer_seg B-14 


W 


wakeups B-13 
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warm 
sec 


wired 


wired 
see 


wired 
see 


wired 
wired 
withd 
willi 


ws_1li 


boot 
boot, warm 
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init linkage 
wil linkage 


supervisor linkage 
ws_ linkage 


_hardcore_data B-15 
anedawe 9-7 

raw A-6 

nkage 2-7, 3-20, B-15 


nkage 2-7, 3-20, B-15 


i-13 
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